[07:38] <jibel> sil2100, I'm reverting the upstart job added yesterday, I'm wondering if that's what prevent lightdm from starting
[07:39] <sil2100> jibel: looks like that's the only change we made, so ACK - but not sure why that's happening ;/
[07:39] <sil2100> jibel: on the other hand...
[07:40] <sil2100> jibel: yeah, let's do that
[07:40] <sil2100> jibel: too bad we can't really check if the new upstart job ran or not - maybe there's some error in the  config file?
[07:41] <jibel> sil2100, the job didn't even start
[07:42] <jibel> sil2100, I'll move the addgroup to the test setup and logout/in before running the tests
[07:42] <sil2100> jibel: ok, thanks
[07:43] <sil2100> jibel: btw. in this case, is there a way of getting the container of the test when it times out? Since I don't see the link to the archive
[07:45] <jibel> sil2100, the archive is here for ATI http://10.97.4.138/otto/saucy-i386-20130624-0916/archive/
[07:45] <jibel> for example the tarball for the latest platform test is http://10.97.4.138/otto/saucy-i386-20130624-0916/archive/ubuntu_13.10_saucy_salamander_alpha_i386_20130624.1372137898.otto
[07:47] <sil2100> jibel: how do I extract the link id? Since the date of the link I can guess, but then it's -0916 <- are these the hours?
[07:47] <sil2100> jibel: normally otto says at the end where to look for the container
[07:48] <jibel> sil2100, right, and that's where I found it. Which job doesn't have the link?
[07:48] <didrocks> sil2100: hours, yeah ;)
[07:49] <sil2100> jibel: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/203/label=autopilot-ati/console <- here, but I see a mention to "Container 'saucy-i386-20130624-0916' stopped", so I guess I know what to use now ;)
[07:51] <jibel> sil2100, interesting, it looks like a bug that the link is not displayed on timeout :)
[07:53] <tsdgeos> greyback: did you have time to have some look at the LVWPH thing?
[07:56] <greyback> tsdgeos: I didn't, but I will today
[07:59] <greyback> tsdgeos: let me do a quick read to get familiar with the code, then we can chat so you can explain to me how it actually works
[07:59] <tsdgeos> oka
[08:07] <sil2100> jibel: give me a sign once it's reverted, ok? :)
[08:07] <sil2100> I'll re-run the stacks then
[08:09] <jibel> sil2100, it's reverted. I'm trying to do the same differently but currently facing gtk and gobject segfaults when the session restarts
[08:09] <sil2100> huh
[08:12] <mzanetti> katie: good morning. the lockscreen tweaks you suggested are landed
[08:13] <katie> mzanetti, good morning
[08:13] <katie> mzanetti, great news
[08:14] <sil2100> jibel: any way I can help?
[08:15] <dpm> morning mhr3, pstolowski, for the scopes tutorial, we're installing the binary on /usr/lib/x86_64-linux-gnu/unity-scope-openclipart/openclipart - that makes the tutorial a bit more complex, as we then require a build system to determine the x86_64-linux-gnu part in the path and replace it in the Exec= line of the DBUS .service file. Would it be ok to install to /usr/bin instead?
[08:15] <dpm> I'd like to make the tutorial simple, but at the same time, I'd like to make sure we install to the standard location for scopes
[08:15] <jibel> sil2100, that's fine, I'm testing a fix and should have something working within 15min
[08:16] <mhr3> dpm, once the scope loader branch lands, you'll be installing a .so, and that should definitely go somewhere in /usr/lib/...
[08:17] <mhr3> +arch_triplet of course
[08:18] <dpm> mhr3, gotcha. But as we're not yet creating a .so, I guess for the purposes of the first tutorial iteration, it should be ok to install to /usr/bin, and then update the tutorial and code when the scope loader branch lands?
[08:21] <mhr3> dpm, why complicate it later, when it can remain the same? :)
[08:21] <mhr3> ie be complicated from the start :P
[08:23] <dpm> mhr3, if I understood it correctly, the .service file will go away, so if that's the case, we won't need to do the .service.in file Exec= line replacement in the tutorial's makefile, so things should even be easier. Is this assumption correct?
[08:23] <mhr3> dpm, probably not in the first iteration, might happen later
[08:24] <mhr3> for now we'll still have the .service file even once it's a module
[08:25] <mhr3> and it'll say something like Exec=scope-dbus-runner /path/to/the.so
[08:25] <dpm> mhr3, ok, thanks, I'll bring the Exec line replacement bits back into the tutorial, then
[08:25] <mhr3> or maybe scope-dbus-runner /path/to/the.scope
[08:25] <dpm> ok, that makes it clearer, thanks!
[08:26] <mhr3> dpm, well the latter would allow you to get rid of the arch triplet
[08:26] <mhr3> as .scope files are not arch-specific
[08:28] <mhr3> although ultimately that only means that the .scope file will need to include path to the .so together with the triplet, so you just can't get rid of it :)
[08:28] <dpm> bummer
[08:29] <mhr3> well, unless you convince platform that scopes don't need to be tripeltted
[08:30] <seb128> mhr3, well, if those are not arch specific, they can go to /usr/share?
[08:30] <mhr3> fwiw compiz's plugins aren't
[08:31] <mhr3> seb128, they're native binaries
[08:31] <seb128> mhr3, binary = arch specific (e.g compiled code)?
[08:31] <nic-doffay> mzanetti, looks like the one branch didn't land.
[08:31] <nic-doffay> Reapproving now
[08:31] <jibel> sil2100, I added the notion of setup-hook to otto, place any executable in ./usr/local/share/otto/setup-hooks/ and it will be executed at the end of otto-setup
[08:31] <mzanetti> nic-doffay: wait
[08:31] <nic-doffay> Jenkins.
[08:31] <mhr3> seb128, yes
[08:31] <nic-doffay> mzanetti, ?
[08:31] <mhr3> "native binary"
[08:31] <mzanetti> nic-doffay: Saviq wanted to give it a look too
[08:31] <jibel> sil2100, I added a hook that adds ubuntu to group autopilot
[08:32] <mzanetti> nic-doffay: or which one are you talking about?
[08:32] <jibel> sil2100, you can re-run the stacks
[08:32] <sil2100> jibel: \o/ Good idea :)
[08:32] <nic-doffay> mzanetti, launcher folding.
[08:32] <sil2100> jibel: excellent! Awesomeness
[08:32] <seb128> mhr3, right, I misread your ".scope files are not arch-specific"
[08:32] <seb128> mhr3, ignore me ;-)
[08:33] <Saviq> nic-doffay, mzanetti yeah, I'll have a quick look soon
[08:38] <sil2100> jibel: seems to work! I ran the QA stack and the tests started running correctly :)
[08:40] <jibel> sil2100, great, no segfault from compiz or a libg(tk|object) ?
[08:42] <sil2100> jibel: hmmm, no segfault, but I got a UInputError('"/dev/uinput" does not exist or is not a character device file - verify that the uinput module is loaded',) again on autopilot autopilot tests, let me check the container
[08:43] <sil2100> jibel: i.e. as if the ubuntu user was not added to the autopilot group again
[08:44] <sil2100> Will know in a moment
[08:44] <nic-doffay> Saviq, I'm writing a small test to compare the TV with the current ListItems (since even I'm unfamiliar with exactly what they look like once implemented) are there any off the top of your head that you think I can just skip?
[08:44] <sil2100> jibel: although I see /var/log/upstart/otto-setup.log: I: Adding user ubuntu to group autopilot
[08:44] <nic-doffay> By TV I mean the sidebar..
[08:44] <Saviq> nic-doffay, not sure what you mean?
[08:45] <Saviq> nic-doffay, they're really completely different components, only thing to compare is the behaviour
[08:45] <Saviq> nic-doffay, which is kind of visual
[08:45] <nic-doffay> Saviq, yeah that's why I'm doing this test.
[08:45] <nic-doffay> So design can see the behaviour side by side.
[08:46] <Saviq> nic-doffay, mhm
[08:46] <sil2100> Strrrange
[08:46] <sil2100> jibel: it seems that the ubuntu user is correctly added to autopilot
[08:46] <Saviq> nic-doffay, biggest issue with the sidebar is it doesn't do mouse input (on purpose)
[08:46] <nic-doffay> Saviq, so in your opinion should just that be worked on and then shown?
[08:46] <Saviq> nic-doffay, so comparing side-by-side is gonna be difficult
[08:47] <sil2100> jibel: I'll look into why, but on your side all is ok ;) Diving in!
[08:47] <Saviq> nic-doffay, just compare what the doc describes, and the SDK ListItems
[08:47] <Saviq> nic-doffay, I don't think the UTV implementation has anything to do here - it's just something we could start working off of when we decide what needs to be worked on
[08:47] <vesar> I'm getting module "Unity.Notifications" is not installed". Any pointers what to install to  get around it?
[08:48] <Saviq> vesar, qtdeclarative5-unity-notifications-plugin
[08:48] <vesar> Saviq, thanks
[08:48] <Saviq> vesar, should have gotten installed through ./build -s, did it not?
[08:49] <jibel> sil2100, the device is probably protected by the container. It should by allowed in the config and bindmounted from the host, let me try something
[08:49] <vesar> Saviq, no it didn't for me at least. I ran rm -rf ../unity_build, ./build -s, ./build -c
[08:50] <sil2100> jibel: that makes sense and would rationally explain what's going on
[08:51] <Saviq> vesar, are you on trunk? from lp:unity/8.0?
[08:51] <vesar> Saviq, no. That is one of mzanettis launcher branches
[08:52] <dednick> Saviq: ping. would you happen to have anymore review of indicators-client branch yet?
[08:52] <Saviq> dednick, never got to it yet, but it's at the top of my TODO, so something'll be there for sure
[08:53] <dednick> Saviq: :) ok. no prob
[08:53] <Saviq> dednick, there's one thing that you replied to, though, the setSource() with properties
[08:53] <Saviq> dednick, you wrote that they're dynamic, but what's the problem there?
[08:53] <Saviq> dednick, I didn't mean that you should just write js objects {prop: "value"} in QML
[08:54] <Saviq> dednick, but export a compatible map from C++
[08:54] <Saviq> dednick, and just pass it to setSource instead of doing the thing in onLoaded
[08:55] <jibel> sil2100, http://paste.ubuntu.com/5797934/ in r226
[08:55] <jibel> applied and deployed
[08:55] <sil2100> uh :)
[08:56] <sil2100> I wonder how those tests passed in the past?
[08:58] <dednick> Saviq: ok. were you meaning doing a:
[08:58] <dednick> Loader.setSource("x.qml", { "indicatorProperties": indicatorProperties } )    OR,
[08:58] <dednick> Loader.setSource("x.qml", { "busName" : indicatorProperties["busName"]; ... })
[08:58] <dednick> excuse the bad qml.
[08:58] <sil2100> jibel: let me re-run QA then, thanks!
[08:59] <Saviq> dednick, the latter, but the { } object built in C++
[08:59] <jibel> sil2100, if it fails again, I'm out of idea :)
[08:59] <Saviq> dednick, so, Loader.setSource("x.qml", indicatorProperties), ideally
[09:01] <sil2100> jibel: ouch!
[09:01] <sil2100> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/215/label=autopilot-ati/console
[09:01] <sil2100> jibel: 2013-06-25 09:00:39,573 ERROR Can't start lxc container
[09:02] <jibel> bah
[09:08] <dednick> Saviq: I'm not exactly sure what you mean by the c++ map. Is it a specific type of object which does the "property transfer"?
[09:09] <Cimi> mzanetti, doing your review, sorry yesterday afternoon got headache and mostly stop working...
[09:10] <Saviq> dednick, I *think* a QVariantMap should work
[09:11] <dednick> Saviq: ok. i'll give it a try
[09:12] <dednick> Saviq: i actually click what you mean now. I didnt realise you can just pass a map and it would set all the individual props for you.
[09:12] <Saviq> dednick, yeah, I felt there was some misunderstanding
[09:15] <jibel> sil2100, I re-ran QA http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-ati/216/console
[09:16] <jibel> but it failed, can you check why
[09:17] <Saviq> dednick, I was trying to read through the code to find out whether it would work http://qt.gitorious.org/qt/qtdeclarative/blobs/5f1b7bf39298dafdd07e576eec2a6a367e80b264/src/quick/items/qquickloader.cpp#line463
[09:18] <Saviq> dednick, and as long as http://qt.gitorious.org/qt/qtdeclarative/blobs/5f1b7bf39298dafdd07e576eec2a6a367e80b264/src/quick/items/qquickloader.cpp#line899 can deal with it
[09:18] <Saviq> dednick, then it should
[09:18] <dednick> Saviq: yeah, i think it should be ok
[09:18] <dednick> will know in a few minutes
[09:18] <Saviq> dednick, cool, thanks
[09:22] <nic-doffay> Saviq, just added the ExpandingDropDown item to a test. Thing is it references the dropDown component which is null. Do you have an idea why this is the case?
[09:23] <Saviq> nic-doffay, it needs to talk to the Sidebar, to be able to find out how far it can / has to expand
[09:23] <Saviq> nic-doffay, actually
[09:24] <Saviq> dropDown in ExpandingDropDown is just an internal object (AbstractExpandingDropDown)
[09:24] <Saviq> nic-doffay, you need to make sure it's available, too
[09:24] <jibel> sil2100, hm, inside the container the device uinput simply doesn't exits
[09:25] <nic-doffay> Saviq, so the dropDown properties are set by the parent sidebar item?
[09:26] <nic-doffay> Because atm it has all the aliases which reference the dropDown.
[09:26] <Saviq> nic-doffay, by whatever uses ExpandingDropDown, yes
[09:27] <Saviq> nic-doffay, EDD is just a wrapper around the Abstract one
[09:27] <Saviq> nic-doffay, so it's not necessarily the sidebar, but just something that sets it up correctly
[09:27] <nic-doffay> Saviq, got it.
[09:29] <dednick> Saviq: needs to be an object :(
[09:30] <Saviq> dednick, yeah, that's what I was afraid of, we'd need to cast ourselves
[09:30] <Saviq> dednick, not worth it, probably
[09:35] <sil2100> jibel: hmm
[09:35] <sil2100> jibel: I thought that every Ubuntu system has that device, as the module should be built in?
[09:37] <greyback> tsdgeos: found 1 bug, can you check it: https://code.launchpad.net/~aacid/unity/UseC++LVWPH/+merge/168073/comments/381628
[09:37] <tsdgeos> greyback: is it the one opening the app?
[09:37] <tsdgeos> just found that myself
[09:37] <tsdgeos> ok, so no :D
[09:37] <greyback> tsdgeos: I resize the LVWPH, but it doesn't redraw
[09:38] <tsdgeos> true, that's easy to fix
[09:38] <greyback> yep, should be
[09:38]  * tsdgeos investigates the open bug he just found first
[09:38] <greyback> I'm doing more functional testing, and have read about 30% of the code so far
[09:39] <greyback> I'm gathering questions, so I'll be bothering you later
[09:42] <tsdgeos> oki
[09:43] <sil2100> jibel: actually... hmmm!
[09:46] <nic-doffay> Saviq, here's what my test looks like at the moment. I'm getting a label at the top but nothing's being appended to the dropDown.
[09:46] <nic-doffay> https://pastebin.canonical.com/93345/
[09:47] <sil2100> jibel: I'm investigating that, since maybe we shouldn't even run those tests
[09:47] <Saviq> nic-doffay, unless you have an isolated issue, I'm afraid I can't help, just dig through it - put some console.log()s in ther eto see what's happening
[09:50] <jibel> sil2100, ok, but I don't understand why this device is not there while it's on the host. what we do is pretty straightforward. it's a bindmount udev, cp the content, umount. Unless it's removed afterwards it should be there
[09:53] <sil2100> jibel: we could probably work-around it by creating the device with mknod by ourselves, but I wonder why it's not being copied
[09:53] <sil2100> jibel: since I confirmed with the guys and having /dev/uinput seems essential
[10:09] <jibel> sil2100, that's what I did to unblock the situation, now I get /var/local/autopilot/autopilot.log: UInput: UInputError('"/dev/uinput" cannot be opened for writing',)
[10:09] <jibel> pushing another fix
[10:09] <jibel> at some point we'll succeed
[10:14] <jibel> sil2100, this run should be good http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-ati/222/console
[10:14] <jibel> at least it'll get rid of that uinput error
[10:15] <jibel> it's like if the udev rule from python-autopilot didn't apply actually
[10:24] <sil2100> \o/
[10:25] <sil2100> jibel: oh?
[10:25] <sil2100> Maybe because we're doing that copy of the container
[10:28] <sil2100> mlankhorst: hi!
[10:28] <sil2100> mlankhorst: do you know how the testing of the new X-stack is proceeding?
[10:29] <mlankhorst> afaik it's ready
[10:29] <sil2100> \o/
[10:30] <sil2100> seb128: ^ ? Do you know anything about that?
[10:30] <seb128> sil2100, did you read the call from testing email from mlankhorst on ubuntu-devel@?
[10:31] <sil2100> seb128: uuh, no, but let me make sure I'm on that list then? I thought I was
[10:31] <mlankhorst> but it seems people are more interested in retiring pandaboard than x-stack, so I have all the test results I need ;)
[10:31] <seb128> sil2100, https://lists.ubuntu.com/archives/ubuntu-devel/2013-June/037386.html
[10:32] <seb128> mlankhorst, well, people are more interested in making sure that the xorg upgrade doesn't break unity or Mir or slow down work from other teams by breaking the system of the engineers working there
[10:32] <mlankhorst> mir's not really affected, it is just a small patch on top of X
[10:33] <sil2100> seb128: thanks, it seems I was not subscribed to that mailing list sadly...
[10:33] <seb128> sil2100, you should subscribe ;-)
[10:33] <sil2100> seb128: I did just now ;)
[10:34] <mlankhorst> and their ddx's would need another rebuild too, but that should be about it..
[10:34] <seb128> mlankhorst, ok, let's wait to hear back from olli today and give them a few extra days of testing then we can copy the xorg update to saucy
[10:34] <sil2100> mlankhorst: so, when do you think we could get things pushed to -proposed ?
[10:35] <mlankhorst> when seb128 thinks it's ok really, I looked at the mir xorg parts before and it seems that the ddx's would just need another rebuild bump, and the xserver patch rebased :/
[10:37] <sil2100> jibel: I see that the uinput error is no more on the -ati machine - did you also do the same for -intel? Since in the latest QA test result -intel was still failing because of that
[10:37] <sil2100> jibel: thanks for dealing with this issue btw.!
[10:38] <mlankhorst> brb, food
[10:42] <jibel> sil2100, done, deployed everywhere
[10:42] <sil2100> \o/
[10:43] <sil2100> Re-running stuff then!
[10:45] <mhr3> didrocks, gentle reminder about master scopes virtual pkg :)
[10:46] <didrocks> mhr3: do you mind gently reminding me that in ~2 hours? :)
[10:46] <didrocks> I think I'll handle it then!
[10:47] <sil2100> mhr3: were you able to find out something regarding the DBus issues with unity? ;)
[10:47] <didrocks> sil2100: did you gently reminding him? :)
[10:48] <mhr3> didrocks, reminder set up ;)
[10:49] <didrocks> ;)
[10:50] <mhr3> sil2100, nope, didn't see you guys ping me about a live system that can be diagnosed
[10:51] <sil2100> Didn't know you were waiting for that! Ok, let me remind you next time we run and run into that
[10:55] <Cimi> MacSlow_, file:///home/cimi/Development/unity/8-launcher-new-folding/Shell.qml:31:1: module "Unity.Notifications" is not installed
[10:55] <Cimi>      import Unity.Notifications 1.0 as NotificationBackend
[10:55] <Cimi> MacSlow_, which is the package? :)
[10:56] <MacSlow_> Cimi, it's...
[10:56] <MacSlow_> Cimi, qtdeclarative5-unity-notifications-plugin
[10:56] <Cimi> MacSlow_, we should add to ./build -s
[10:57] <MacSlow_> Cimi, well it is part of the build-script
[10:57] <Cimi> MacSlow_, it didn't install here
[10:57] <MacSlow_> Cimi, when did you pull from trunk last time?
[10:57] <Cimi> MacSlow_, mmm I used this branch
[10:57] <Cimi> 8-launcher-new-folding
[10:57] <MacSlow> Cimi, don't know that one :)
[10:58] <sil2100> jibel: all passed \o/ Awesome!
[10:58] <sil2100> jibel: for the qa stack, re-running all the others now!
[10:58] <Cimi> in any case doesn't start here :\
[10:58] <MacSlow> Cimi, perhaps it does not have the fixes regarding the build-script
[10:58] <MacSlow> Cimi, did you install it?
[10:58] <MacSlow> Cimi, manually I mean
[10:59] <jibel> sil2100, Good news, now trying to find why the udev rule doesn't create that device.
[10:59] <Cimi> I did apt-get install
[11:00] <MacSlow> Cimi, do you have /usr/lib/x86_64-linux-gnu/qt5/qml/Unity/Notifications.1 ?
[11:00] <MacSlow> Cimi, well path of course depends on you machine architecture
[11:01] <Cimi> I'm trying with trunk
[11:10] <Cimi> who codes in a vm?
[11:10] <Cimi> I run ./run and nothing happens
[11:10] <Cimi> oh no, it does now
[11:11]  * Cimi shuts up
[11:11] <Cimi> mzanetti, ping
[11:13] <MacSlow> Cimi, you have you dependency-issue sorted out now?
[11:13] <Cimi> MacSlow, yep
[11:13] <mzanetti> Cimi: hey!
[11:13] <Cimi> hey boss
[11:14] <mzanetti> boss? there's a misunderstanding somewhere
[11:14] <Cimi> lol
[11:14] <mzanetti> :D
[11:14] <Cimi> anyway slave
[11:14] <mzanetti> better now :D
[11:14] <Cimi> I am not sure the thin divider asset is correct
[11:14] <Cimi> is it?
[11:15] <Cimi> looks opposite to the other dividers we have, white on top and black at bottom
[11:15] <mzanetti> Cimi: wow! good catch!
[11:15]  * mzanetti fixes
[11:15] <mzanetti> Cimi: this happens because the launcher can be inverted
[11:15] <Cimi> ok
[11:16] <mzanetti> which in fact rotates the whole thing by 180 degrees and I forgot swapping the divider in that case
[11:21] <Trevinho> fginther: this should fix your issues https://code.launchpad.net/~3v1n0/bamf/ignore-autostart-desktop-files/+merge/171274
[11:22] <Trevinho> seb128: yours as well ^^ ;)
[11:22] <seb128> Trevinho, great! do you need testing for that fix?
[11:24] <Saviq> tsdgeos, mzanetti, looking at QQuickLoader::setSource() http://qt.gitorious.org/qt/qtdeclarative/blobs/5f1b7bf39298dafdd07e576eec2a6a367e80b264/src/quick/items/qquickloader.cpp#line525
[11:25] <Saviq> can you think of something we could build in C++ to pass as the second argument?
[11:25] <Saviq> other than v8::Object, that is
[11:28] <tsdgeos> Saviq: nope, why you need that?
[11:28] <Saviq> tsdgeos, we need to set some properties on the item when it's Loaded
[11:28] <Saviq> tsdgeos, but that's fine, we're just doing it in a loop
[11:28] <tsdgeos> for my LVWPH tests i needed to excercise one of those functions that took a v8thing and i ended up going the C++ -> metaCall to JS -> function
[11:28] <tsdgeos> :D
[11:28] <Saviq> was hoping there would be a better way with Loader.setSource()
[11:29] <Saviq> tsdgeos, nice...
[11:31] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/fix_sdk_graphicaleffects/+merge/171276 <- quick-fix
[11:32] <didrocks> sil2100: approved, please redeploy :)
[11:32] <sil2100> didrocks: thanks :)
[11:32] <didrocks> sil2100: FYI, I'm changing the versioning scheme as per #ubuntu-release, more on that soon
[11:34] <mzanetti> Saviq: sorry. was focused on something. is the question still valid?
[11:34] <Saviq> mzanetti, if you can come up with something, sure
[11:35] <mzanetti> Saviq: I don't understand the use case yet
[11:35] <Saviq> mzanetti, you have a Loader
[11:35] <Roxastry> hello all. Who know, how set icon in system tray without save in file system form application if this icon storage in pixbuf in application.
[11:35] <Roxastry> sorry for my bad English =)
[11:35] <Saviq> mzanetti, a source url, and a set of properties to set on Loader.item when it's constructed
[11:35] <Saviq> mzanetti, that's exactly what Loader.setSource(url, properties) is for
[11:36] <mzanetti> Saviq: something like pageStack.push("MyPage.qml", {foo: "bar}) ?
[11:36] <Saviq> mzanetti, yeah
[11:36] <Saviq> mzanetti, but in our case we'd need to provide the properties map from C++
[11:36] <Saviq> mzanetti, and AFAICS that's impossible short of building a v8::Object in our C++, which I'd rather not do :)
[11:37] <Saviq> mzanetti, and we have a "workaround" by the means of a loop, so it's mostly an academic problem
[11:37] <mzanetti> Saviq: can I see the workaround?
[11:40] <Saviq> mzanetti, sure
[11:40] <Saviq> mzanetti, https://code.launchpad.net/~nick-dedekind/unity/8.indicators-client/+merge/168022/comments/377685
[11:41] <Saviq> mzanetti, line 55 of the diff mentioned
[11:42] <mzanetti> Saviq: didn't you say in C++?
[11:42] <Saviq> mzanetti, the workaround is in QML ;)
[11:43] <Saviq> mzanetti, but "indicatorProperties" come from C++
[12:20] <didrocks> mhr3: it's already on its own binary package in fact
[12:21] <didrocks> (the -common one)
[12:21] <didrocks> it just needs to provide a virtual package to be changeable I guess
[12:24] <didrocks> mhr3: so, this should be enough: https://code.launchpad.net/~didrocks/libunity/provides-untity-scopes-json-def/+merge/171288
[12:24] <didrocks> sil2100: I've deployed the new versionning scheme on all stack, but unity/head
[12:26] <didrocks> sil2100: if you want to build a new package from this stack, you'll have to redeploy it (from latest cupstream2distro-config trunk) first
[12:28] <didrocks> sil2100: ah, unity stopped, so deploying
[12:32] <jibel> sil2100, FYI the problem with uinput is that udev doesn't create input devices in the container (other input devices under /dev/input are bind mounted from the host).
[12:32] <jibel> So our workaround with mknod is good enough, I'll just move it to autopilot setup instead of otto.
[12:44] <sil2100> didrocks: ACK, thanks!
[12:45] <sil2100> jibel: excellent, thanks for the heads-up, I guess this workaround is good enough for us for now
[12:47] <sil2100> didrocks: is a re-run for every stack required, or can I publish those with the old versioning still?
[12:47] <dednick> dandrader: ping
[12:47] <dandrader> dednick, pong
[12:47] <dednick> dandrader: hey. how's the dda work going?
[12:48] <dandrader> dednick, it's done. but I can't propose it as it depends on https://code.launchpad.net/~dandrader/unity/8_dragHandle/+merge/170172
[12:48] <dandrader> which no one reviewed yet
[12:49] <dednick> dandrader: i can take a look if you want
[12:49] <dandrader> dednick, that would be great
[12:52] <mhr3> didrocks, nooooo
[12:53] <mhr3> didrocks, should have provided more details, sorry, i was talking about the home scope
[12:53] <mhr3> didrocks, there we have a bunch of .scope files, and want to split them up into a separate bin pkg
[12:54] <mhr3> didrocks, but since you already did that for the json definition as well, i think that's useful, afterall there should be different client-scopes for desktop and phone :)
[12:57] <dednick> dandrader: one quick one. there is a conflict with trunk.
[13:02] <Saviq> mzanetti, re: snapping... shouldn't the preferredHighlightBegin/End do exactly that? i.e. you need to set it to values that make sure that it's flat initially?
[13:02] <mzanetti> Saviq: yeah... but the preferredhighlight should be in the center
[13:03] <mzanetti> the design requirement is to distribute space equally at top/bottom
[13:03] <mzanetti> actually I think this is a bug in the ListView
[13:03] <Saviq> mzanetti, ah, so currentItem is always in the middle?
[13:03] <mzanetti> because if you drag it manually you can well make it stick unfolded at the end
[13:04] <mzanetti> but setting contentY does not do the trick
[13:04] <mzanetti> Saviq: yes. currentItem is in the middle - but I don't use the currentItem/Index notation here
[13:05] <mzanetti> Saviq: hmm... wait a sec... I have an idea...
[13:05] <Saviq> mzanetti, you could always try flick() - it seems to do the trick when tapping on bottom/top
[13:05] <mzanetti> Saviq: yeah... just not a fan of such stuff... feels like a bad hack. but yeah. that would be my last-resort thing I guess
[13:06] <dandrader> dednick, fixed
[13:06] <Saviq> mzanetti, perfectly agree
[13:10] <tvoss_> didrocks, ping
[13:12] <mzanetti> Saviq: found it: ListView.ApplyRange - the view attempts to maintain the highlight within the range. However, the highlight can move outside of the range at the ends of the list or due to mouse interaction.
[13:12] <Saviq> mzanetti, yup
[13:12] <mzanetti> Saviq: thats why it only works when dragging/flicking
[13:20] <fginther> sil2100, thanks for fixing the uinput permissions issue, what was the problem?
[13:22] <sil2100> fginther: hi! jibel did most of the fixing, since adding ubuntu user autopilot permissions was not enough, as it seemed that the otto container did not have /dev/uinput at all
[13:22] <mzanetti> Saviq: ok... giving up. If you don't mind I'll go with the flick() in onCompleted. seems to work prefectly fine
[13:22] <sil2100> fginther: we worked around that by creating it with mknod during otto autopilot setup
[13:22] <sil2100> And it works!
[13:23] <fginther> sil2100, that is strange. I thought uinput was one of the default udev rules. hmmm
[13:23] <sil2100> fginther: since /dev/uinput is on the machine, but gets lost during the copy
[13:23] <Saviq> mzanetti, yeah, just add a comment what it does
[13:23] <tedg> sil2100, Did the dbusmenu stuff pass last night?
[13:23] <fginther> sil2100, oh, so is that a consequence of the fs overlay?
[13:24] <sil2100> tedg: yes! I think it did, as I saw build was OK for indicators - how were you able to fix that flacky problem?
[13:24] <sil2100> fginther: most probably
[13:24] <tedg> sil2100, One of the flaky ones were timeouts, one test we decided to disable until we can figure out more info.
[13:25] <Saviq> jeez django-users... "how can I do something in a function after return"...
[13:25] <Saviq> it's like the worst place to be subscribed to
[13:26] <sil2100> tedg: that's a good choice I guess, since it wouldn't make sense to block the indicator stack just because of this one test
[13:31] <mterry> kgunn, Saviq: I have to skip standup, will fill in minutes later
[13:31] <Saviq> mterry, k
[13:32] <kgunn> mterry: later
[13:32] <Saviq> paulliu, standup
[13:33] <mterry> (i moved yesterday, am waiting for internet hookup to arrive, but it is late)
[13:42] <mzanetti> MacSlow: bottomline: sync with veebers
[13:43] <didrocks> sil2100: yes :)
[13:44] <MacSlow> mzanetti, ok... funny that there's an stand-up entry for my from yesterday although I had a day off :)
[13:44] <didrocks> mhr3: hum, that json file is used for what in the upstream side?
[13:44] <mzanetti> MacSlow: hehe
[13:44] <MacSlow> mzanetti, thanks for the heads up!
[13:44] <mzanetti> MacSlow: yeah... mostly because we were syncing with chris on autopilot and you're on that too currently
[13:44] <didrocks> tvoss_: pong
[13:45] <mmrazik> didrocks: shall we add mc-return to "trusted" users? Otherwise (unless somebody re-approves) the following will stay where it is:
[13:45] <mmrazik> https://code.launchpad.net/~ivenvd/compiz/compiz.fix_1193792/+merge/170975
[13:45] <mhr3> didrocks, to know which scopes are installed by default
[13:45] <didrocks> mhr3: oh right, then, we have the diff
[13:46] <didrocks> mmrazik: I think he can be trusted for compiz
[13:46] <didrocks> mmrazik: is it a global thing or per project?
[13:46] <MacSlow> mzanetti, ah... just saw that branch... that's my python regressions-tests put there
[13:46] <mmrazik> didrocks: its a global thing. It essentially says who is allowed to run code on the private jenkins
[13:47] <mmrazik> once there it is not a big difference against which project you create the MP
[13:47] <didrocks> mmrazik: ok, I think it's fine in that case, as long as this is not linked to merge approval rights :)
[13:47] <mzanetti> MacSlow: not sure about what branch you are talking, but yes, such a regression-tests branch has been mentioned in the meeting yesterday
[13:47] <mmrazik> didrocks: nope. You still need to be part of the right launchpad team to do that
[13:47] <didrocks> mhr3: you want one binary package per master scope file?
[13:48] <mmrazik> fginther: FYI -- I'm adding mc-return to the jenkins config as trusted
[13:48] <mmrazik> (see above)
[13:48] <mhr3> didrocks, nah, keep them all in one pkg
[13:48] <MacSlow> mzanetti, it's the notification-backend branch from the api-team, where I put my python-based regression tests... I guess they'll be used as a starting point for the autopilot-tests
[13:50] <MacSlow> mzanetti, ah... veebers is Chris from NZ
[13:51] <didrocks> mhr3: ok, then creating unity-scopes-master virtual package?
[13:51] <didrocks> mhr3: sorry, btw, but with /usr/share/unity/scopes/info.scope, shouldn't I have an info master scope?
[13:52] <mhr3> didrocks, perhaps unity-scopes-master-default ?
[13:52] <mzanetti> MacSlow: it might make sense if you just ping him in the morning when you join the channel. usually he's around for half an hour or so
[13:52] <mhr3> didrocks, cause there can be more master scopes in different pkgs
[13:53] <MacSlow> mzanetti, yeah... also just writing him an eMail.
[13:53] <mzanetti> cool
[13:53] <didrocks> mhr3: but each master scope doesn't mean we will see them in the dash, right?
[13:53] <didrocks> mhr3: I don't have an "info" icon at the bottom
[13:54] <mhr3> didrocks, no, but you have it in the Categories filter in home
[13:54] <didrocks> in my mind, there were a 1 to 1 mapping
[13:55] <mhr3> time to change your mind :)
[13:55] <didrocks> mhr3: so, it's because of no "Icon/SearchHint/ContentHint"?
[13:57] <mhr3> didrocks, we have lots of scopes, so ones that are actually visible in the dash bar is a separate setting these days
[13:57] <fginther> mmrazik, ack
[13:57] <mhr3> didrocks, (in dconf)
[13:57] <didrocks> mhr3: ah, but the choice of what to display is made within the master scope list only, right?
[13:59] <mhr3> didrocks, no, it's not limited just to master scopes, you can put "subscopes" there as well
[14:00] <didrocks> mhr3: so master scopes are just defining the categories (for deduplication) in a view (being home scope or a particular view, like the video ones)
[14:00] <didrocks> one*
[14:01] <mhr3> didrocks, yep, but all scopes expose everything that's needed for them to be displayed in the view
[14:01] <didrocks> mhr3: excellent, I think I got it then :)
[14:01] <didrocks> let me split quickly the unity-scope-home
[14:01] <didrocks> (I prefer to get it right in my mind first ;))
[14:02] <mhr3> sure, it's good when you know what you're doing :)
[14:02] <didrocks> mhr3: isn't it?
[14:14] <didrocks> mhr3: https://code.launchpad.net/~didrocks/unity-scope-home/ship-master-scopes-def/+merge/171311
[14:16] <mhr3> didrocks, shouldn't there be a hard dep?
[14:17] <mhr3> didrocks, i mean, the master scopes are now just recommended, right?
[14:17] <mhr3> i think we can easily do hard dep, if there's a virtual pkg, no?
[14:17] <didrocks> mhr3: right, with the alternative, it can be dep, but I think recommends would be more appropriate?
[14:18] <didrocks> mhr3: I don't really want to do a circular dep, so that would mean the definition won't dep on the service
[14:18] <didrocks> if you are fine with that, I can change it
[14:18] <mhr3> didrocks, hmmm, well without home scope the definitions are pretty useless
[14:19] <didrocks> mhr3: right, that's why there is the second dep
[14:19] <didrocks> mhr3: but they are not harmful either :)
[14:19] <mhr3> didrocks, the primary reason i don't like recommends is upgrades
[14:20] <didrocks> mhr3: ah, well, in that case, both will be delivered at the same time
[14:20] <mhr3> but if you tell me it's fine, i'll be fine :)
[14:20] <didrocks> mhr3: no, I can remove the deps the other way around
[14:20] <didrocks> let me push this
[14:20] <didrocks> mhr3: rev 128
[14:21] <mhr3> ok, i think i'm happy with that
[14:22] <mhr3> didrocks, thx a lot
[14:22] <didrocks> mhr3: yw ;)
[14:23] <mhr3> didrocks, btw i expected there's more magic associated with virtual pkgs... :)
[14:25] <didrocks> mhr3: there is some implicit :)
[14:26] <didrocks> mhr3: like for the iso to build, you need to have the real package first
[14:26] <didrocks> and no dep versionning on a virtual package :p
[14:34] <Saviq> dednick, you made me almost go down in the review progress with the indicators-client move :P
[14:34] <Saviq> s/down/back/
[14:34] <dednick> Saviq: :)
[15:13] <dandrader> mzanetti, ping
[15:13] <mzanetti> dandrader: pong
[15:14] <dandrader> mzanetti, is it by design that dragging the launcher beyond the middle of the screen causes it to hide itself on release?
[15:14] <mzanetti> dandrader: hmm... probably not. don't have anything that would specify that.
[15:16] <mzanetti> dandrader: well, it should do that when minimizing an app... but I know, it does it without an app too
[15:16] <mzanetti> which is probably not the really good
[15:43] <mhr3> Saviq, should be a quick one - https://code.launchpad.net/~mhr3/unity/category_content_type/+merge/171343
[15:45] <Saviq> mhr3, we're wrapping at 120 columns, can you please un-wrap line 33 of the diff?
[15:47] <mhr3> are you saying i have to resize my terminal? :-O
[15:47] <mhr3> Saviq, pushed
[15:48] <Saviq> mhr3, you need to stop living in the '80s ;P
[15:52] <mhr3> Saviq, lol, good one
[15:56] <Saviq> mhr3, I hate to be doing this to you... but we're doing 4 space indents...
[15:57] <Saviq> /we need astyle config around
[15:57] <mhr3> Saviq, eh, my bad, modelines would be nice though
[15:57] <Saviq> mhr3, indeed
[15:58] <tsdgeos> pre-commit hook, not sure if possible in bzr, gstreamer had it afair
[15:58] <tsdgeos> in git
[15:59] <Saviq> tsdgeos, not possible in bzr (unless you install it in your ~/.bzr)
[16:00] <Saviq> tsdgeos, I could think of a generic hook for your ~/.bzr that would use some config file checked into your repository
[16:00] <Saviq> tsdgeos, so possible in that sense
[16:01] <mhr3> Saviq, hope the newline between the case and the { is fine
[16:01] <tsdgeos> sure, would still need "manual intervention"
[16:01] <mhr3> Saviq, "case Foo: {" just looks wrong :P
[16:01] <tsdgeos> so people that are not "the usual hackers" still would have the problem
[16:01] <Saviq> mhr3, +1
[16:01] <seb128> tedg, mhr3: jbicha just pinged us about lp #1155968 ... is the new version fine for unity's stack?
[16:01] <seb128> or do you guys would need to port your stuff first?
[16:01] <Saviq> mhr3, we don't yet have a clear style guide in there, am trying to get to that sooner rather than later
[16:02] <tedg> seb128, They can be dual installed (I have that on my system now).  But, yes, I'd like the new version.
[16:02] <Saviq> mhr3, it's most probably gonna be Qt style, though, as it's all just Qt code, really
[16:02] <seb128> tedg, ok, thanks, I will have a look to that then
[16:02] <mhr3> Saviq, yea, whatever, it just a style... i'll get slapped for the first commit, but hopefully then i'll remember
[16:02] <Saviq> mhr3, :)
[16:04] <mhr3> Saviq, but i have no problems with it only cause it's a 20line diff commit ;P
[16:05] <Saviq> mhr3, I do feel I'd be bitten by the lack of braces around single-line case blocks
[16:05] <Saviq> mhr3, but at least in that case it dies on compilation
[16:06] <Saviq> so yeah +1
[16:07] <mhr3> Saviq, it's not common to do braces around cases, needs to be done only when you have a new variable there
[16:07] <Saviq> mhr3, right
[16:08] <Saviq> mhr3, but yeah, my point - here you can't be bitten the same as with if
[16:09] <mhr3> right, i just like switches, it's miles easier to read
[16:10] <mhr3> seb128, eh, sorry, i'm not aware of breakage that new zg would cause
[16:11] <mhr3> seb128, is it needed for something? or just jbicha wants the latest and greatest?
[16:11] <seb128> mhr3, k, let's see
[16:13] <seb128> mhr3, well, both, I had to patch e.g gedit's back to undo https://git.gnome.org/browse/gedit/commit/?id=20d860b6500e8f9a8143be4df306225e206664d6
[16:13] <seb128> mhr3, tedg seems keen to get the new version as well (I think they said the performances are improved)
[16:13] <seb128> tedg, you wanted the update for specific reason?
[16:14] <mhr3> seb128, yea, ted wanted the no-dbus db reading
[16:14] <tedg> seb128, I'd like to use it for tracking in HUD.  Not sure I'll get to the port this cycle as I'm getting bogged down with other stuff.  :-(
[16:14] <tedg> But that's why I'm interested
[16:14] <mhr3> tedg, you don't need new zg for that ;)
[16:15] <tedg> mhr3, I need it for it to be reasonably performant.  The DBus reading is why we didn't use ZG at the start.
[16:16] <mhr3> tedg, oh, i thought you just wanted the new ontology...
[16:16] <tedg> mhr3, No, that's just #defines, I can steal that easily enough :-)
[16:16] <mhr3> indeed
[16:16]  * tedg already knows of that evil <evil laugh>
[16:18] <mzanetti> Saviq: tested this, works fine: https://code.launchpad.net/~saviq/unity/8.flipped-support/+merge/171061
[16:18] <mzanetti> Saviq: want me to top-approve?
[16:19] <mzanetti> or wait a bit in the hope that the adb-over-tcp gets supported before we switch to flipped containers?
[16:19] <mzanetti> ah, screw it.
[16:19] <mzanetti> I'll top-approve
[16:26] <Saviq> mzanetti, yeah, it's ready to top-approve
[16:26] <Saviq> mzanetti, it supports both, so it's fine
[19:02] <mterry> Kaleo, heyo.  Do you know if there's an API in Qt that will expose whether the display device is on or not?  I haven't found one, but I thought I'd ask someone that knew Qt well
[19:20] <mhall119> tvoss_: loved those screenshots of other DEs on XMir
[19:21] <mhall119> tvoss_: can I safely s/Unity Next/Unity 8/ on unity.ubuntu.com?
[19:22] <mhall119> also, we have documentation up there about running tests, do we have any documentation about writing them?
[19:23] <tvoss_> mhall119, glad you liked them, the replace should be fine! kgunn, any objections?
[19:24] <kgunn> mhall119: go for it
[19:26] <tvoss_> mhall119, blender works, too :) but need to take a video, screenshot is a bit boring in this case
[19:29] <mhall119> tvoss_: kgunn: on http://unity.ubuntu.com/getinvolved/development/unitynext/ under "Build dependencies" it says that build -s will:
[19:29] <mhall119> Build and install lp:libunity/phablet, lp:unity/phablet-mods, lp:hud/phablet and lp:unity-lens-people locally
[19:29] <mhall119> are those project branches still correct?
[19:31] <kgunn> mhall119: i was just looking this over
[19:31] <kgunn> i don't think they are right anymore...
[19:35] <dandrader> mhall119, check the latest state of the build script. it has changed quite a bit overtime.
[19:36] <dandrader> mhall119, If I'm not mistaken it also works only in saucy now
[19:36] <kgunn> dandrader: yep...
[19:36] <kgunn> i was actually changing the wiki atm
[19:37] <kgunn> but then feeling lost....as i think lots of stuff has changed
[19:37] <kgunn> mhall119: sorry...just realized you're editing too...i just bailed out
[19:38] <mhall119> kgunn: let me save my edits, then you can jump in
[19:38] <mhall119> kgunn: I'm only editing the WP page, not the wiki
[19:38] <kgunn> mzanetti: do you have a quick decoder ring for the ./run options ? wrt lockscreen (e.g. if set...is there a default pin & passphrase)
[19:38] <kgunn> and how to set lock (on the desktop)
[19:39] <kgunn> mhall119: that's what i meant...i was in WP
[19:43] <mhall119> kgunn: okay, I'm done now, you can go in and make any changes you need
[19:49] <mterry> kgunn, pin is 1234
[19:50] <mterry> kgunn, password is password I believe
[19:50] <kgunn> mterry: ta
[19:55] <kgunn> mterry: are you able to run on desktop (e.g. ./run)
[19:55] <kgunn> ?
[19:56] <mterry> kgunn, you need -f for that
[19:56] <kgunn> mterry: actually same result
[19:57] <mterry> kgunn, what's the result?
[19:57] <kgunn> unless you tell me i screwed up by trying to run w/o -f one time
[19:57] <mterry> no
[19:57] <kgunn> mterry: it complains about unity.notifications not installed (shell.qml:31:1)
[19:58] <mterry> kgunn, oh yeah, that's new.  I got that last Friday when I was playing with trunk.  I didn't investigate, since it wasn't blocking me, but I thought it was unusual
[19:58] <kgunn> mterry: so did the shell window actually launch for you ? (i get nothing)
[19:59] <mterry> Saviq, mzanetti : do you know what package Unity.Notifications is in?  Seems to be missing from ./build -s run because ./run -f complains about missing Unity.Notifications.  ^
[19:59] <mterry> kgunn, no
[20:00] <mterry> kgunn, I also get nothing, just the error about notifications
[20:00] <mterry> MacSlow wrote the notification stuff, but he's not on here now
[20:06] <kgunn> mterry: not sure why it failed....weird....just manually did a apt-get install of unity-notifications-impl-1 (per the ./build script...) and it worked
[20:06] <kgunn> i now see a shell
[20:08] <mterry> kgunn, aw awesome
[20:09] <mterry> I guess I need to do that too
[20:20] <kgunn> mterry: ah-ha...because its not really "unity-notifications-impl-1"...its "qtdeclarative5-unity-notifications-plugin"
[20:21] <dandrader> the missing unity.notifications was added to the "build --setup" script on revision 36
[20:21] <dandrader> kgunn, mterry ^
[20:22] <mhall119> is there a reason why Search isn't enabled on the Unity 8 home lens?
[20:22] <mhall119> and a way to enable it
[20:23] <Saviq_> mhall119, because it's not the real home scope
[20:24] <Saviq_> mhall119, you could drop it from the list of mappings in DashContent.qml
[20:24] <Saviq_> mhall119, but that would probably kill your dash due to the amount of data (we're fixing that)
[20:24] <mhall119> ah, ok
[20:24] <mhall119> I'm really looking forward to using the smart scopes on my N7
[20:33] <kgunn> mterry: dandrader ....acutally, figured it out...if you have any failures from the apt-get update after the build add's ppas....then it bails out
[20:33] <kgunn> e.g. i had some armhf failures lingering in there
[20:34] <kgunn> once i cleaned that up...it installs notifications just fine
[20:36] <kgunn> dandrader: last one...what diff does  -m "no mouse touch" make...tested both, at least i can't see a real diff
[20:37] <kgunn> dandrader: actually...at least no mouse touch doesn't reveal the launcher once in the dash
[20:38] <dandrader> kgunn, if you disable the conversion of MouseEvents into TouchEvents then components that handle only touch won't work (such as DirectionalDragArea)
[20:39] <dandrader> kgunn, right not part of the edge drags is MouseArea based and part DirectionalDragArea based, so you get mixed results
[20:39] <dandrader> s/not/now
[20:39] <kgunn> dandrader: ok...is there some specific way that's useful ?
[20:40] <kgunn> like why would you ever want to use -m (sorry if its obvious)
[20:40] <dandrader> kgunn, well, if you wanna a setup that matches the device you will want to disable that conversion
[20:41] <dandrader> kgunn, but it's more of an hypothetical scenario than a real one
[20:42] <kgunn> dandrader: yeah...i guess from a perception point of view...no -m seems to work just fine (and more like i'd expect)
[22:07] <kgunn> mhall119: hey, i was getting around to looking at updating instructions....but....seems the page has gone missing
[22:07] <kgunn> http://unity.ubuntu.com/getinvolved/unitynext
[22:07] <kgunn> nvmd....
[22:07] <kgunn> i see
[22:07] <kgunn> unity8
[22:07] <kgunn> cool