[07:49] <Saviq> MacSlow, ping
[07:49] <Saviq> MacSlow, because we can't rely on "real" notifications implementation to be there for testing, http://pastebin.ubuntu.com/5779672/
[07:54] <Saviq> MacSlow, and http://pastebin.ubuntu.com/5779685/ for the depends
[07:54] <Saviq> dandrader, dude, go to sleep! ;P
[07:54] <dandrader> Saviq, :)
[07:59] <MacSlow> Saviq, ah ok...
[07:59] <MacSlow> Saviq, but didn't I add the "qtdeclarative5-unity-notifications-plugin | unity-notifications-impl" line already...
[08:00] <Saviq> MacSlow, doesn't look like it
[08:01] <MacSlow> Saviq, odd... swear I had that done... probably missed a commit (before a revert)
[08:01] <Saviq> MacSlow, yeah, happens
[08:01] <MacSlow> Saviq, are those two patches going to make it pass?
[08:01] <Saviq> MacSlow, qmluitests - yes it should
[08:02] <MacSlow> Saviq, because looking at the test-run results there are no failing tests... of course locally it's always working
[08:02] <MacSlow> Saviq, https://jenkins.qa.ubuntu.com/job/unity-8.0-ci/116/artifact/unity-phablet-qmluitests-saucy/work/results/testNotifications.xml/*view*/
[08:02] <Saviq> MacSlow, because you have unity-notifications on your QML import path
[08:03] <Saviq> MacSlow, but https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/88/testReport/junit/%28root%29/qmltestrunner/tst_Notifications__compile/
[08:04] <Saviq> MacSlow, for autopilot to pass we need to make lp:unity-notifications to be available in distro/PPA
[08:21] <Saviq> MacSlow, I've uploaded unity-notifications to ppa:phablet-team - with this we should be able to pass CI
[08:21] <dednick> Saviq: ping
[08:21] <Saviq> dednick, pong
[08:21] <MacSlow> Saviq, I've pushed the suggested chagnes as r24 of my branch
[08:22] <Saviq> MacSlow, the first pass might not happen as the package needs to build in the PPA
[08:22] <Saviq> MacSlow, but I'll keep you posted
[08:22] <MacSlow> Saviq, yeah... we need to give the jenkins-machinery some time
[08:22] <MacSlow> Saviq, I'll keep an eye on it too :)
[08:22] <Saviq> MacSlow, btw, it passed locally for you because you had lp:unity-notifications somewhere on your QML import path
[08:23] <Saviq> MacSlow, but qmluitests don't install the Depends (and shouldn't)
[08:23] <MacSlow> Saviq, yeah... did that manually on my desktop-machine and later on the phone too.
[08:23] <dednick> Saviq: having trouble with unity8 lenses on saucy.
[08:24] <dednick> Saviq: links dont seem to work anymore. have we changed to new libunity for unity8?
[08:24] <Saviq> dednick, we're in the process
[08:24] <Saviq> dednick, I hope today
[08:24] <Saviq> MacSlow, yeah, I just built it for the phone and ran your branch and got notifications with no notify-osd in sight
[08:24] <Saviq> dednick, https://code.launchpad.net/~unity-team/unity/8.new-libunity/+merge/167733
[08:25] <Saviq> dednick, but we need to land notifications first, so that we can get rid of lp:nux/phablet
[08:25] <Saviq> dednick, 'cause that crashes the new-libunity branch
[08:25] <MacSlow> Saviq, yeah... as long as I don't reboot my Nexus I get the new ones too when someone phones/texts me :)
[08:25] <dednick> Saviq: ok. not sure if it's related, but autopilot tests dont seem to be working  either.
[08:25] <dednick> Saviq: So no ci success.
[08:26] <Saviq> MacSlow, why as long as you don't reboot? does notify-osd start even though the shell takes the dbus name?
[08:26] <Saviq> MacSlow, or do you mean you haven't actually installed the package, but running from the local build?
[08:26] <MacSlow> Saviq, just locally build on the phone
[08:27] <Saviq> MacSlow, cool
[08:27] <MacSlow> not any package
[08:28] <Saviq> dednick, hmm CI was passing yesterday, no?
[08:28] <dednick> Saviq: dont know, but my branch is failing and trunk AP isn't working on my desktop. possibly just my branch/setup though
[08:29] <Saviq> dednick, yeah locally won't work
[08:29] <Saviq> dednick, 'cause libunity is conflicting
[08:29] <dednick> Saviq: i see
[08:31]  * Saviq reboots
[08:41] <Saviq> MacSlow, ugh, *No copyright* in notifications.js
[08:41] <Saviq> MacSlow, can you please add?
[08:41] <MacSlow> Saviq, sure
[08:42] <Saviq> dednick, I've restarted the failed jobs, but there were only a few failed tests, so AP works fine, just that the tests failed, let's see how it goes
[08:42] <dednick> Saviq: my failure seems to be something to do with lock screen not showing
[08:43] <Saviq> dednick, yeah, I saw that, let's see what happens
[08:47] <dandrader> tsdgeos, do you see it as a "random autopilot failure" -> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/193/testReport/unity8.tests.testhud/TestHud/test_show_hud_button_dont_open_Nexus_10_/
[08:47] <dandrader> ?
[08:49] <mzanetti> Saviq: hey. about that wifi bug. is anyone working on it?
[08:49] <Saviq> mzanetti, not actively, no
[08:49] <tsdgeos> nooooooo
[08:49] <tsdgeos>    Actual   (lvwph->m_minYExtent): 323,333
[08:49] <tsdgeos>    Expected (323.333): 323,333
[08:49] <mzanetti> Saviq: hmm... thats the one that makes the phone useless for me right now
[08:50] <tsdgeos> :'(
[08:50] <Saviq> mzanetti, feel free to jump on it
[08:50] <Saviq> tsdgeos, did javascript just bite you?
[08:50] <mzanetti> Saviq: ok. any pointers already are we all at 0 with this?
[08:50] <tsdgeos> Saviq: nah, just trying to test a double number
[08:50] <mzanetti> tsdgeos: haha :P
[08:51] <tsdgeos> dandrader: no video for that? we used to have autopilot videos
[08:51] <mzanetti> tsdgeos: there is something like fuzzyCompare iirc
[08:51] <tsdgeos> mzanetti: this one is supposed to be using it
[08:51] <Saviq> tsdgeos, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/193/artifact/unity8.tests.testhud.TestHud.test_show_hud_button_dont_open%20%28Nexus%2010%29.ogv
[08:51] <tsdgeos> i guess it's a too small fuzzy
[08:51] <Saviq> tsdgeos, the fuzziness is a parameter, I think?
[08:52] <tsdgeos> should be
[08:52] <tsdgeos> need to find how to pass it
[08:52] <tsdgeos> dandrader: the video is 40 seconds of amazing nothing :D
[08:52] <Saviq> dandrader, yeah, I've already restarted CI on it
[08:52] <tsdgeos> i'll blame the slowlyness of the machine
[08:53] <Saviq> dandrader, it seems like it's a random unlock failure
[08:53] <Saviq> mzanetti, I don't think we have any details beyond https://bugs.launchpad.net/touch-preview-images/+bug/1183065
[08:53] <dandrader> Saviq, tsdgeos, ok. thanks
[08:53] <Saviq> mzanetti, but it does not feel like something we can fix in the shell
[08:54] <Saviq> mzanetti, indicators-client at most
[08:54] <mzanetti> Saviq: no... seems network-manager related
[08:55] <tsdgeos> actually can't find the fuzzy compare that let's me pass the fuzyness down :-S
[08:55] <tsdgeos> ok, i'll add more 3333333333
[08:55] <tsdgeos> worked now :D
[08:55] <Saviq> tsdgeos, verify( < ), verify ( > )
[08:55] <Saviq> ?
[08:55] <tsdgeos> QCOMPARE(lvwph->m_minYExtent, 323.3333333333333);
[08:55] <mzanetti> lol
[08:55] <mzanetti> not sure how reliable that is
[08:56] <Saviq> tsdgeos, http://qt-project.org/doc/qt-5.0/qtcore/qtglobal.html#qFuzzyCompare-8 didn't work?
[08:57] <greyback> tsdgeos: 970/3 ?
[08:57] <tsdgeos> Saviq: that's the same, qcomare uses fuzzycompare for doubles
[08:57] <Saviq> tsdgeos, yeah, just saw that
[08:57] <tsdgeos> greyback: oh you the mathematic ;_)
[08:57] <Saviq> yeah, we have a maths PhD in da house!
[08:58] <greyback> well it might make it more likely to equate on different arches
[08:58] <Saviq> +1
[08:58] <greyback> tis all
[08:58] <Saviq> mzanetti, looks like there's enough people looking into the battery drain
[08:58] <Saviq> mzanetti, unless you have some input for them
[09:00] <mzanetti> Saviq: yeah... I just read through the bug...
[09:00] <mzanetti> Saviq: still unity8 shouldn't loop at 40% cpu if network bails out
[09:01] <Saviq> mzanetti, I suspect it's because the network indicator goes crazy
[09:01] <Saviq> mzanetti, and so we're updating the network indicator UI constantly
[09:01] <mzanetti> hmm... that could be
[09:02] <Saviq> damn I'm melting here...
[09:02] <mzanetti> +1
[09:02] <mzanetti> its so hot, the fans of my PC are spinning even when the PC is off :D
[09:02] <Saviq> lol
[09:03] <Saviq> 27.7°C indoors at 68% humidity
[09:03] <Saviq> and I'm adding to the humidity all the time...
[09:05] <Saviq> dandrader, https://code.launchpad.net/~dandrader/unity/8_bottomBarDDA/+merge/170164/comments/379080 these don't look like random failures anymroe
[09:05] <Saviq> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/196/artifact/unity8.tests.testhud.TestHud.test_show_hud_button_dont_open%20%28Nexus%2010%29.ogv
[09:05] <Saviq> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/196/artifact/unity8.tests.testhud.TestHud.test_show_hud_button_dont_open%20%28Nexus%204%29.ogv
[09:06] <luv> jo tak xrdp s pulseaudio fakt funguje ale byl to boj :-)
[09:07] <Saviq> luv, I assume wrong channel? :)
[09:07] <Saviq> dandrader, although it could be slowliness
[09:07] <luv> ah, sry :-)
[09:07] <Saviq> dandrader, as it seems for the nexus 4 it tries to drag from the bottom before the app gets into focus
[09:09] <dandrader> Saviq, yes, I've just added some debug logs to DirectionalDragArea to pin point what's causing it
[09:09] <dandrader> Saviq, I suspect it's the minimum speed requirements for the drag gesture
[09:09] <Saviq> dandrader, mhm
[09:09] <Saviq> didrocks, if phone-app depends on notify-osd, but unity8 (>= 7.81.0) will do what notify-osd did to date, how would you set up the Depends / Provides / Conflicts?
[09:10] <didrocks> Saviq: will talk with you in a few, trying to unscrew ubuntu iso not building because of web credentials for now
[09:10] <Saviq> didrocks, sure
[09:10] <Saviq> didrocks, I could also bug someone else :)
[09:11] <Saviq> seb128, your turn ^
[09:11] <Saviq> seb128, both should be installable in parallel (as we want notify-osd still for unity7, but unity8 handles it internally)
[09:12] <seb128> Saviq, hey
[09:12] <seb128> Saviq, you can do "Depends: notify-osd | unity (>= 7.90)
[09:13] <seb128> Saviq, you usually list the preferred option first
[09:13] <Saviq> seb128, right
[09:13] <seb128> so likely unity8 | notify-osd
[09:13] <Saviq> seb128, thanks, will do
[09:14] <seb128> Saviq, does unity8 really conflicts with notify-osd (like using same filenames on disk or same dbus namespace)?
[09:14] <Saviq> seb128, same dbus name, yes
[09:15] <Saviq> seb128, but only one should be running at any given time
[09:15] <seb128> ok, like any notification daemon
[09:15] <Saviq> seb128, i.e. if unity8 is started, notify-osd shouldn't get dbus-activated
[09:15] <seb128> ok
[09:15] <Saviq> seb128, so in theory we should be fine
[09:15] <seb128> so don't make those conflict or anything
[09:15] <Saviq> yeah
[09:15] <seb128> some users might still want both
[09:15] <seb128> notify-osd to use with e.g xubuntu
[09:15] <Saviq> yeah, we definitely want both
[09:15] <seb128> or unity7
[09:16] <Saviq> exactly
[09:16] <dandrader> Saviq, ah, right. watching the videos it seems autopilot is doing the bottom-edge drag before the application-coming-to-foreground animation completes.
[09:16] <seb128> great
[09:16] <Saviq> dandrader, yeah
[09:16] <dandrader> it's all so incredibly slow there...
[09:16] <Saviq> yeah, software rendering :/
[09:18] <Saviq> seb128, TBH it feels like it shouldn't be a dependency of the phone-app at all...
[09:18] <Saviq> seb128, or maybe it should...
[09:18] <Saviq> seb128, it's needed for calls, so maybe...
[09:18] <seb128> Saviq, we don't make every notification user depends on a notification daemon, we rely on the desktop environment to provide the feature
[09:19] <Saviq> seb128, yeah, but here it's slightly more involved - i.e. you can't answer a call without either notify-osd or unity8...
[09:19] <seb128> Saviq, I guess you don't want notify-osd if you need interactions then
[09:19] <seb128> Saviq, notify-osd doesn't support actions
[09:19] <Saviq> seb128, the phablet notify-osd does interactions
[09:19] <seb128> oh ok
[09:19] <Saviq> which is being decommissioned anyway
[09:19] <seb128> so yeah, Recommends: unity8 | notify-osd
[09:19] <seb128> at least
[09:20] <didrocks> (ok, waiting for feedback) I would say that we even don't need the |, it should just depends on unity8
[09:20] <Saviq> yeah
[09:20] <didrocks> and having the notify-osd startup script detects the session name
[09:20] <didrocks> to not start if dbus activated
[09:20] <Saviq> didrocks, it only starts dbus-activated, afaict
[09:21] <seb128> didrocks, Saviq: well, the | is handy if you want to test the phone-app on desktop today
[09:21] <didrocks> Saviq: yeah, we have a script on notify-osd to "only starts" in the right session name
[09:21] <Saviq> didrocks, k
[09:21] <didrocks> seb128: shouldn't we get unity8 soon? I think both will come at the same time
[09:21] <seb128> we should stop dbus activating the notification daemon at all
[09:21] <didrocks> (as we are blocking on the converged indicator-messages anyway)
[09:22] <Saviq> seb128, yeah, but desktop notify-osd doesn't help, since there's no interactions :)
[09:22] <seb128> right
[09:22] <seb128> no strong opinion either way, to be fair phone-app will be on the image with unity8
[09:22] <Saviq> yup
[09:22] <seb128> so that discussion is probably not worth the 15 minutes we already spammed IRC for :p
[09:22] <seb128> either depends/recommends including unity8 will do
[09:22] <Saviq> ok, dropping the dependency altogether
[09:23] <Saviq> lol
[09:23] <Saviq> Recommends it is
[09:23] <seb128> ;-)
[09:26] <didrocks> seb128: do you remember how we do handle starting notify-osd only on the ubuntu session? it seems to be an alternative now and no more a conditional startup script
[09:26] <didrocks> which shouldn't be an issue in the unity8 session as it will own the dbus name I guess
[09:26] <Saviq> yes
[09:27] <Saviq> unless something tries to notify before unity8 starts...
[09:27] <didrocks> Saviq: well, we'll figure out if that's the case, but unity8 will be, as compiz today, the first component to start :)
[09:27] <Saviq> yup :)
[09:28] <didrocks> if there are races, we'll figure it out
[09:29] <seb128> didrocks, I'm not sure, I didn't follow the recent changes ... I think Debian and others wanted to stop dbus activating notification services at all
[09:29] <seb128> didrocks, they wanted to just make those part of the desktop, so it should be the shell of session manager doing the activation
[09:29] <didrocks> seb128: ok, well, the current solution should work, we'll refine if needed :)
[09:29] <didrocks> right
[09:29] <didrocks> thanks seb128, Saviq
[09:30] <Saviq> didrocks, seb128 yup, thanks
[09:34] <seb128> didrocks, shrug, ok, the divert is still there, the content of the file is not
[09:35] <seb128> didrocks, robru broke it when he inlined the packaging: http://launchpadlibrarian.net/124264231/notify-osd_0.9.34-0ubuntu5_0.9.35daily12.11.28-0ubuntu1.diff.gz
[09:35] <seb128> didrocks, see the notify-osd-0.9.35daily12.11.28/data/org.freedesktop.Notifications.service.in in that upload
[09:35] <didrocks> seb128: yeah, so if you install notify-osd and switch to a xfce session, you will get notify-osd
[09:35] <seb128> yes
[09:35] <didrocks> seb128: not sure we care though, TBH
[09:35] <seb128> no, we don't
[09:36] <seb128> we should drop dbus activation at all
[09:36] <didrocks> right
[09:36] <seb128> but on another day
[09:36] <seb128> atm it just works so let's not create extra work
[09:36] <didrocks> exactly :)
[09:38] <Cimi> mzanetti, ping
[09:42] <Saviq> dednick, it seems the pinlock failures are consistent https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/198/?
[09:42] <Saviq> mzanetti, any pointers ^?
[09:42] <Saviq> dednick, maybe some trunk merge issue?
[09:43] <Saviq> dednick, mzanetti the pinlock / passlock screens don't show up at all
[09:43] <Saviq> tsdgeos, btw, didn't you fix the wrong placement in ListView with sections https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/198/artifact/unity8.tests.testlockscreen.TestLockscreens.test_unlock%20%28Keylock%29.ogv ?
[09:43] <dednick> Saviq: yah. thought they would be. i think the lightdm greeter prompt request isn't coming through
[09:44] <dednick> whatever that means. i was waiting on the results before going to check it out though
[10:03] <Saviq> MacSlow, the import path is wrong
[10:03] <Saviq> MacSlow, you have the brace after /plugins
[10:03] <Saviq> MacSlow, should be before
[10:04] <Saviq> MacSlow, and there's a missing "S" in qmltest_DEFAULT_
[10:04] <Saviq> MacSlow, why didn't you just apply my patch from
[10:04] <Saviq> http://pastebin.ubuntu.com/5779672/
[10:05] <MacSlow> Saviq, did copy&paste in vim... must have hit x :)
[10:05] <Saviq> MacSlow, and notification.js, not notifications.js
[10:06] <Saviq> MacSlow, next time, please do `patch -p0`
[10:06] <Saviq> MacSlow, and actually check locally that it worked
[10:06] <Saviq> MacSlow, http://pastebin.ubuntu.com/5779993/
[10:08] <Saviq> MacSlow, the autopilot failure is unrelated, too
[10:35] <tsdgeos> Saviq: i did, question is, is the patch in saucy? and if it is, did i fix only one of the cases and there are more?
[10:35]  * tsdgeos checks if the patch is there on saucy
[10:39] <tsdgeos> Saviq: patch still not there
[10:39] <Saviq> tsdgeos, that's... good :)
[10:39] <tsdgeos> according to Mirv is in the beta place? https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1183350
[10:40] <tsdgeos> not sure what we can do to tell him to put it in proper
[10:50] <dandrader> mzanetti, where does the logger.warning() stuff goes to when running autopilot tests in my desktop?
[10:50] <mzanetti> dandrader: stdout
[10:50] <mzanetti> dandrader: unless you specify "-f xml" when calling autopilot
[10:50] <mzanetti> dandrader: in that case it will end up in the produced xml file
[10:53] <dandrader> mzanetti, now seeing the logged stuff anywhere. but "print 'foo'" does work
[10:53] <dandrader> mzanetti, I'm running the tests like this:
[10:53] <dandrader> tests/autopilot$ autopilot run unity8.tests.testhud.TestHud.test_show_hud_button_dont_open
[10:53] <dandrader> s/now seeing/not seeing
[10:54] <mzanetti> dandrader: I think that should print to stdout/stderr
[10:54] <mzanetti> dandrader: give me a second to finish proposing that branch, then I can look at it
[11:06] <Saviq> mzanetti, https://code.launchpad.net/~unity-team/unity-api/launcher/+merge/167586/comments/379166
[11:06] <Saviq> mzanetti, really just a few cosmetic changes
[11:08] <mzanetti> Saviq: ack
[11:15] <Saviq> mzanetti, btw, do we have any more hardware where we could run qmluitests on? it gets crowded there
[11:23] <mzanetti> Saviq: hmm... might be related that some VM's are detached because they are half-prepared for the switch away from unity
[11:23] <mzanetti> err... nux
[11:23] <Saviq> mzanetti, mhm
[11:25] <Saviq> mzanetti, should be sorted today, then
[11:26] <sil2100> didrocks: oooh oooh! What's the threshold for unity tests?
[11:26] <sil2100> didrocks: the number of failures I mean?
[11:26] <didrocks> sil2100: IIRC, 17 or something like that
[11:26] <Saviq> mzanetti, btw, I thought we should've been able to just use the newly prepared VMs already?
[11:27] <didrocks> Saviq: but you have also a number of accepted regressions
[11:27] <didrocks> sil2100: ^
[11:27] <didrocks> grrr :p
[11:27] <sil2100> \o/ Ok, so I keep my fingers crossed, since one machine finished the tests and it had 14 failiures only!
[11:27] <didrocks> sil2100: why?
[11:27] <didrocks> yeah, let's hope so :)
[11:27] <sil2100> Waiting for the other to finish
[11:27] <Saviq> didrocks, I don't accept regressions! :P
[11:27] <Saviq> mzanetti, i.e. we're probably not gonna drop ppa:phablet-team in the end, just unity and nux from the ppa
[11:27] <didrocks> Saviq: lucky that you have 0 flacky tests! :)
[11:28] <Saviq> didrocks, I wouldn't go that far
[11:28] <Saviq> didrocks, who do you think clicks "rebuild" all the time :D
[11:28] <didrocks> Saviq: ah, so you need to get a threshold to not block everything every time
[11:28] <mzanetti> Saviq: ok, I'll check on enabling the VM's
[11:28] <didrocks> Saviq: I don't want to have that as part of the automated machinery
[11:28] <Saviq> :D
[11:28] <didrocks> especially when we have 200+ packages to deliver
[11:28] <didrocks> so 200 clicks is not acceptable, even if it's just 10% :p
[11:28] <Saviq> didrocks, no, it's not that bad http://s-jenkins:8080/job/unity-phablet-autolanding/
[11:29] <Saviq> didrocks, if jenkins doesn't barf
[11:29]  * didrocks doesn't know the ip of s-jenkins TBH :p
[11:29] <didrocks> since it changed…
[11:29] <Saviq> didrocks, https://jenkins.qa.ubuntu.com/job/unity-8.0-autolanding/?
[11:29] <Cimi> mzanetti, ping
[11:30] <didrocks> Saviq: 20-25% of runs
[11:30] <didrocks> Saviq: if you scale that to all our stacks and components, it's still 50 reruns :)
[11:30] <Saviq> didrocks, yeah, we'll get better, too :)
[11:30] <didrocks> Saviq: hence this threshold to be quite relaxed on "some" flacky tests
[11:30] <didrocks> we'll discuss it once we'll put unity 8 under daily release I guess :)
[11:31] <Saviq> didrocks, yup, most often we get autopilot issues
[11:31] <Saviq> didrocks, that fail 'cause they're so slow
[11:31] <didrocks> similar than most of issues with unity 7
[11:31] <mzanetti> Cimi: pong
[11:31] <Cimi> mzanetti, I read your review, there are some things which are there for a reason
[11:32] <Cimi> mzanetti, for example, starting from basicmenu
[11:32] <Cimi> mzanetti, the listitems are not themed in the sdk
[11:33] <Cimi> mzanetti, so all the code you see, from the background to the thindivider, is for styling them
[11:33] <mzanetti> Cimi: but basicmenu inherits from ListItem
[11:33] <mzanetti> Cimi: then don't inherit from ListItem
[11:33] <mzanetti> Cimi: at least not from ListItems.Standard
[11:33] <Cimi> mzanetti, and from what? I need the controls?
[11:33] <mzanetti> Cimi: what controls?
[11:33] <Cimi> the icon, or the buttons
[11:34] <mzanetti> Cimi: you don't use the icons except in one case. In all the others you have a dead property in your public api, some wated resources because of the empty Image {} and worst of all, if someone uses the dead property it even breaks your component
[11:35] <Cimi> so I should do standard and reimplement the code for the controls?
[11:35] <Cimi> sorry, empty
[11:35] <mzanetti> Cimi: I'd say yes. If this should be used by other people, the API needs to be clean and safe
[11:36] <Cimi> ok
[11:37] <mzanetti> Saviq: is there a way to hide inherited properties from the public API in qml?
[11:37] <Saviq> mzanetti, I don't think there is
[11:37] <Saviq> mzanetti, simply because everything's public...
[11:40] <Saviq> sil2100, hey, any update on libunity9 / unity from daily-build going into distro?
[11:42] <sil2100> Saviq: I'll have the test results in some moments and all will be known
[11:43] <Saviq> sil2100, awesome
[11:44] <Saviq> ooh we now get a dimmed screen before it goes off completely :D
[11:44] <Saviq> nice one!
[11:54] <didrocks> sil2100: seeing how long the tests are taking, I wonder if we don't have the dbus issue
[11:54] <didrocks> mhr3: you maybe want to jump on the ati machine right now? ^
[11:54] <sil2100> didrocks: I think that machine might be affected indeed...
[11:54] <sil2100> didrocks: since the other was fine
[11:54] <sil2100> didrocks: btw. you think we could force the publication anyway?
[11:55] <didrocks> sil2100: for unity, as we have good results on the other machine, i would say yes
[11:55] <didrocks> sil2100: just run in 2 phases
[11:55] <didrocks> first without "force"
[11:55] <didrocks> to check with packaging changes and so on
[11:55] <sil2100> Of course ;)
[11:55] <didrocks> :)
[11:55] <mhr3> didrocks, let me jump on it
[11:55] <mhr3> didrocks, do i have a timer ticking before it dies?
[11:56] <didrocks> mhr3: I don't know if jibel removed the timeout, but if we still have, you have 10 minutes :)
[11:57] <mzanetti> Saviq: I'm confused. Should I apply your patch then which changes all the launcher api to use named imports? Didn't we just define the guideline to use explicit naming?
[11:58] <Saviq> mzanetti, you didn't read ;)
[11:58] <Saviq> mzanetti, when the import would look like "import Unity.Launcher", I'd rather not have "Launcher" in the registered types
[11:58] <Saviq> mzanetti, so that with a named import you don't have to go Launcher.LauncherModel
[11:59] <Saviq> mzanetti, explicit in class and file names, namespaced when registering - that was what I wrote down
[11:59] <Saviq> mzanetti, but then got hit by the "Item" registration
[11:59] <Saviq> mzanetti, and now I don't know again
[12:00] <mzanetti> ok... I did read but probably in the wrong order... confused shit out of me
[12:04] <Saviq> mzanetti, so for this (and taking dandrader's comment into account)
[12:04] <Saviq> mzanetti, I'll leave it to you
[12:04] <Saviq> to decide
[12:05] <Saviq> I still like named imports better for readability
[12:05] <Saviq> but because there's issues like that (and especially bug https://bugreports.qt-project.org/browse/QTBUG-30730
[12:06] <ricotz> Trevinho, hi, is it known that bamf fires two emits of bamf_matcher.active_application_changed? with following args (OLD_APP, null) and (null, NEW_APP) instead of (OLD_APP, NEW_APP)
[12:06] <mzanetti> Saviq: holy s***... thats a bad bug
[12:06] <Saviq> mzanetti, it's not even considered a bug
[12:06] <Saviq> mzanetti, read Alan's comments :/
[12:06] <Saviq> mzanetti, we need to convince him it really is
[12:07] <mzanetti> ah... because it works without named imports
[12:07] <Saviq> mzanetti, yeah, which is blind luck, Alan said it's not supposed to work
[12:07] <Saviq> which is something I can't accept
[12:08] <Trevinho> ricotz: yeah... but it's also hard to fix without adding idles or something... Since it's impossible to predict wich one is going to be unactivated and which one is activated
[12:08] <sil2100> didrocks: ok, in the meantime, I checked all stacks for the SRU that are ready for release, and the changelogs look ok, there are no packaging changes and all tests pass as expected
[12:08] <sil2100> didrocks: can I publish so that they land in the SRU PPA?
[12:08] <Saviq> MacSlow|lunch, SUCCESS on qmluitests
[12:08] <Trevinho> ricotz: I tried to change that, but it wasn't worth... ricotz probably we should instead just emit the new app activated and check which one was before...
[12:08] <Saviq> MacSlow|lunch, and SUCCESS everywhere else
[12:08] <ricotz> Trevinho, i see, there are even times where its fires 5 emmits
[12:09] <mzanetti> Saviq: ah... I see what he means
[12:09] <mzanetti> Saviq: in C++, you wouldnt do something like: foo(MySingletonClass)
[12:09] <mhr3> :/ i want d-feet, doing it all with dbus-send is not fun
[12:09] <mzanetti> Saviq: but rather foo(MySingletomClass::instance())
[12:09] <Saviq> mzanetti, it's not a class, it's an object of that class
[12:10] <didrocks> sil2100: yeah \o/
[12:10] <mzanetti> Saviq: and one way would be to make the instance() a property of that singleton
[12:10] <Trevinho> ricotz: mh, weird
[12:10] <ricotz> Trevinho, the syntax is fine imo, and if there is a new active window, bamf should figure out what happend before emit
[12:10] <didrocks> sil2100: tell me how it goes, just publish one stack so that we can check :)
[12:10] <didrocks> as it's all brand new and shiny code path :p
[12:10] <mzanetti> Saviq: then you could call in QML: foo(MySingletonClass.instance)
[12:10] <Saviq> mzanetti, but you're not exposing MySingletonClass
[12:10] <Saviq> mzanetti, you're exposing MySingleton
[12:11] <Saviq> mzanetti, and if MySingleton = MySingletonClass::instance()
[12:11] <Saviq> mzanetti, you would do foo(MySingleton)
[12:11] <Saviq> in C++
[12:11] <mzanetti> Saviq: yeah...
[12:11] <ricotz> Trevinho, e.g. emit-queue http://paste.debian.net/plain/11296
[12:11] <ricotz> Trevinho, for one window change
[12:12] <mzanetti> Saviq: just trying to figure why he doesn't think its a bug
[12:12] <Saviq> mzanetti, it must be something weird internally
[12:12] <mhr3> didrocks, ehm, yea, it just shutdown
[12:12] <Saviq> mzanetti, that he didn't express
[12:12] <jibel> didrocks, the timeout is still 2h
[12:12] <Trevinho> ricotz: yes, the problem is that all this depends on the order that the views have on the list... but I also didn't want to introduce delays...
[12:12] <didrocks> mhr3: indeed, did you get time to get any data?
[12:12] <didrocks> jibel: maybe for some days, we should set it to 4?
[12:13] <ricotz> Trevinho, hmm, a delay seems better than doing things 5 times
[12:14] <mhr3> didrocks, not much, i only saw that dbus was working
[12:14] <mhr3> at least introspection was
[12:14] <ricotz> Trevinho, may i pm you?
[12:14] <Trevinho> well, yeah... but then unity "triangles" (showiing the focused app) where not so nice...
[12:14] <Trevinho> ricotz: sure...
[12:14] <mhr3> didrocks, jibel, also, something happened with lxc, it hangs when i lxc-list now
[12:15] <Trevinho> ricotz: however that's something I really wanted to improve, but it needs also to change something in unity probably
[12:15] <didrocks> mhr3: right, it can't stop the container
[12:15] <didrocks> jibel: ^
[12:15] <jibel> mhr3, which machine?
[12:15] <didrocks> E: Test failed to run in 7200 seconds. Aborting!
[12:15] <mhr3> ati
[12:15] <didrocks> 2013-06-19 12:11:46,746 INFO Stopping container 'saucy-i386-20130619-0811'
[12:15] <jibel> mhr3, machine ran out of memory
[12:16] <mhr3> hmm, autopilot was running there, plus i ran dbus-monitor
[12:16] <Saviq> mzanetti, can I ask you to go through https://code.launchpad.net/~macslow/unity/phone-shell-integration-notifications/+merge/168715
[12:16] <mhr3> don't think that should make it run out of memory :)
[12:17] <didrocks> mhr3: it's all your fault again! :p
[12:17] <Saviq> mzanetti, I've been too involved with this to review with a clean heart
[12:17] <mhr3> didrocks, noooooooo..... when i connected there was still like 70mb free
[12:17] <didrocks> that much! you stole 70mb! :)
[12:17] <mhr3> KiB Mem:   8284364 total,  7748368 used,   535996 free,    68360 buffers
[12:17] <mhr3> KiB Swap:  8385532 total,  1260780 used,  7124752 free,  6771776 cached
[12:18] <mhr3> no way this ran out of memory
[12:18] <didrocks> mhr3: so, once sil2100 will have finished with all the runs, I proposed that we force running the tests again
[12:18] <mhr3> 6gb in cache
[12:18] <didrocks> without any timeout
[12:18] <didrocks> in a row
[12:18] <didrocks> (we won't need the machines until the end of day)
[12:18] <didrocks> until it starts hanging again
[12:18] <mhr3> didrocks, sounds good to me
[12:18] <didrocks> jibel: sounds good to you as well? should I increase the timeout? ^
[12:19] <ricotz> Trevinho, alright, i guess there is no other way hacking it with an idle on my side then for now
[12:20] <Trevinho> ricotz: yes :/...
[12:21] <mzanetti> Saviq: yep
[12:22] <didrocks> timeouted change on both intel and ati
[12:25] <sil2100> hmm
[12:25] <dandrader> Saviq, is there a way to check is jenkins is making a build for a given merge proposal?
[12:25] <dandrader> s/is jenkins/if jenkins
[12:25] <sil2100> didrocks: do you want to re-run those tests before publishing the current unity?
[12:25] <dandrader> I'm afraid I might have confused jenkins by overwriting my branch...
[12:26] <Saviq> dandrader, http://s-jenkins:8080/job/unity-8.0-ci/lastBuild/parameters/
[12:26] <didrocks> 13:54:39   sil2100 | didrocks: btw. you think we could force the publication anyway?
[12:26] <didrocks> 13:55:01  didrocks | sil2100: for unity, as we have good results on the other machine, i would say yes
[12:26] <didrocks> sil2100: wasn't your question for that? ^
[12:26] <Saviq> dandrader, and click "Previous Build" if that's not it
[12:27] <Saviq> dandrader, but the jobs cope surprisingly well with overwriting
[12:28] <didrocks> mhr3: ok, see run 176, started it manually, if in 1:15 min, we still have one machine running, maybe it will be good to look at it :)
[12:28] <didrocks> sil2100: relaunched the tests manually for debugging ^ but that doesn't prevent you to publish both indicators and unity
[12:28] <jibel> didrocks, if you want. I've seen that the cache  is never reallocated in some cases, this is a problem I thought was specific to nvidia but I never found the exact conditions to reproduce it.
[12:28] <mhr3> didrocks, k, so time for me to have lunch then :)
[12:29] <didrocks> jibel: oh?
[12:29] <didrocks> mhr3: some time for exercising you mean! :)
[12:29]  * didrocks just wait on sil2100 to publish before going
[12:29] <mhr3> didrocks, yep, i'll exercise my taste buds :P
[12:29] <didrocks> mhr3: you are eating French food? :)
[12:29] <jibel> didrocks, yes that's why we disabled recordmydesktop, to use less memory and be able to run unity tests.
[12:30] <jibel> didrocks, actually on nvidia we hit the wall quicker because it only has 4GB while the ATI box has 8
[12:30] <didrocks> jibel: yeah, the "oh?" was because I read your "I never found the exact conditions to reproduce it" as "I found the exact conditions to reproduce it"
[12:30] <didrocks> jibel: false joy :)
[12:32] <jibel> didrocks, mhr3 anyway, in this state you can consider the machine as dead and reboot it.
[12:33] <didrocks> jibel: the following tests passed, interestingly
[12:33] <didrocks> so was quick enough
[12:33] <didrocks> maybe we will be able to retrigger the state
[12:34] <mhr3> pls don't tell we'll find some kind of bug in lxc itself or in the graphics drivers or something
[12:34] <didrocks> mhr3: it's not lxc for sure as we had it with UTAH
[12:34] <jibel> mhr3, it is not lxc, the problem is the same on hardware
[12:34] <didrocks> graphics driver…
[12:35] <jibel> I mean without lxc
[12:35] <jibel> # (free; sync; echo 3>/proc/sys/vm/drop_caches ; free)|grep Mem
[12:35] <jibel> Mem:       8284364    7847236     437128          0     149464    7086348
[12:35] <jibel> Mem:       8284364    7847912     436452          0     149480    7086332
[12:35] <jibel> ^ that's supposed to free pagecache, dentries and inodes
[12:36] <jibel> and you see that cached mem didnt move
[12:37] <mhr3> jibel, it doesn't on my machine either
[12:37] <jibel> mhr3, if cache is use it's normal, but on the test machine with nothing running most of the cache should have been freed
[12:40] <mhr3> hmm, i have hard time believing that the 3gb the caches take are all in use
[12:42] <jibel> on my machine after (free; sudo sync; echo 3 | sudo tee /proc/sys/vm/drop_caches ; free)|grep Mem cached memory went from 4159844 down to 330792
[12:52] <sil2100> didrocks: back! Publishing indicators first \o/
[12:52] <mzanetti> Saviq: done: https://code.launchpad.net/~macslow/unity/phone-shell-integration-notifications/+merge/168715
[12:52] <didrocks> sil2100: ok :)
[12:56] <sil2100> didrocks: ok, checking the unity test results from the one machine we had - there's not too many failures, 15 of those
[12:56] <didrocks> sil2100: yep, so normal publication to see if we have packaging changes?
[12:57] <sil2100> didrocks: looking at those, but those - although strange, I guess they're not anything serious
[12:57] <sil2100> didrocks: yes
[13:01] <Saviq> mzanetti, thanks
[13:02] <sil2100> didrocks: the changes look ok more or less, I have been thinking if change the change from valac-0.18 to valac without a minimum version requirement in unity-lens-music
[13:02] <didrocks> sil2100: well, that's fine in our case I think, we are not going to downgrade. But nice catch :)
[13:02] <didrocks> sil2100: good for me as well, please publish :)
[13:03] <didrocks> sil2100: then, you are going to publish raring? I'm going to do some exercice, do you want to try one right now?
[13:03] <didrocks> so that we can see it if it lands successfully in the staging sru ppa?
[13:04] <sil2100> didrocks: I published the misc stack before lunch, let's see if it worked
[13:05] <sil2100> didrocks: what was the SRU PPA url?
[13:05] <didrocks> sil2100: https://launchpad.net/~ubuntu-unity/+archive/sru-staging
[13:05] <sil2100> g-c-c-u is there \o/
[13:06] <didrocks> let's see in raring UNAPPROVED
[13:06] <didrocks> sil2100: there as well \o/ https://launchpad.net/ubuntu/raring/+queue?queue_state=1&queue_text=
[13:06] <didrocks> sil2100: you can publish the rest I guess :)
[13:06] <didrocks> Sync from SRU staging ppa, requested by Ubuntu Archive Robot
[13:06] <sil2100> didrocks: ACK, btw. what shuold I do with the webapps stack? Wait for Robert?
[13:07] <didrocks> seb128: FYI, I hope that we'll get some SRU team member syncing them this time ^ :)
[13:07] <didrocks> sil2100: yeah, let's wait for him
[13:07] <sil2100> didrocks: ok ;) Have a good exercise!
[13:07] <didrocks> ok, so one last thing
[13:07] <didrocks> now that indicators is published
[13:07] <didrocks> I think there is the new libusermetrics package
[13:08] <didrocks> yeah :)
[13:08] <didrocks> let's new it!
[13:08] <didrocks> and don :)
[13:08] <didrocks> done*
[13:08] <didrocks> sil2100: thanks, will do!
[13:08] <sil2100> \o/
[13:10] <Saviq> MacSlow, there's some comments from mzanetti on the notifications branch, did you see? easy fixes, too
[13:23] <Saviq> pstolowski, can you do https://code.launchpad.net/~stolowski/phablet-extras/unity-lens-mock-new-api/+merge/167721/comments/376979 ?
[13:23] <pstolowski> Saviq: looking
[13:25] <pstolowski> Saviq: right, updating
[13:25] <Saviq> pstolowski, thanks
[13:26] <Saviq> pstolowski, and didn't we want to rename it to unity-scope-mock already?
[13:26] <Saviq> pstolowski, that can be handled later, though
[13:27] <pstolowski> Saviq: you mentioned this as a possibility, so yeah, let's do it after we land
[13:27] <Saviq> pstolowski, yup
[13:28] <Saviq> pstolowski, notifications are almost ready, I hope we'll be able to merge this, too
[13:28] <pstolowski> Saviq: that would be great :)
[13:28] <Saviq> sil2100, new unity and libunity went into distro, did they? is that what the PS Jenkins Bot spam is about?
[13:29] <sil2100> Saviq: it should be!
[13:29] <Saviq> sil2100, awesomes!
[13:32] <mhr3> didrocks, yey, latestsnapshot mps! are we going to have an update in S soon?
[13:33] <Saviq> mhr3, sil2100 says so ↑ :)
[13:33] <paulliu> Hi, google hangout today? Does anyone have the link?
[13:34] <mhr3> wooo, should read at least a tiny bit of backlog next time :)
[13:34] <sil2100> \o/
[13:34] <mzanetti> Saviq: +#include <unity/SymbolExport.h>
[13:34] <mzanetti> Saviq: does not compute
[13:35] <Saviq> mzanetti, merge trunk
[13:35] <Saviq> greyback, hangout
[13:35] <greyback> yep almost there
[13:35] <Saviq> mzanetti, compute, btw? ;)
[13:35] <Saviq> MacSlow, hangout
[13:35] <mzanetti> Saviq: :D
[13:36] <mzanetti> Saviq: I think its weird how bzr determines what to use if you jut type "bzr merge"
[13:36] <Saviq> mzanetti, it remembers the first one you used
[13:36] <mzanetti> it should always be origin imho
[13:36] <Saviq> mzanetti, and then whatever you did with --remember
[13:44] <sil2100> mlankhorst: hi!
[13:45] <mlankhorst> g'day
[13:45] <sil2100> mlankhorst: hm, were you the one responsible for getting the new X into S? Since I remember didrocks asked to poke someone when we finally release new version of Unity for S
[13:45] <sil2100> To give a green light for the 'new X'
[13:46] <mlankhorst> ok
[13:47] <mlankhorst> well x has been ready for a while now, just needs to be copied from the ppa, with the unity xinput patch applied
[13:51] <sil2100> I need to poke Brandon what's the status of that
[13:58] <sil2100> mhr3: did you look into that dbus issue with unity tests?
[14:04] <mhr3> sil2100, ah, it's hanging again, let's me try to connect to the machine
[14:05] <sil2100> mhr3: thanks! ;)
[14:09] <mhr3> jibel, lxc-attach is hanging :/ any ideas what's up with that?
[14:11] <mhall119> mfisch: ping me when you're around
[14:11] <mfisch> mhall119: just finishing a call, give me a minute
[14:13] <jibel> mhr3, as I said memory is exhausted, oom-killer in action
[14:14] <jibel> [20537.549319] Memory cgroup out of memory: Kill process 4435 (pool) score 47 or sacrifice child
[14:14] <jibel> [20537.549328] Killed process 7677 (sh) total-vm:2268kB, anon-rss:4kB, file-rss:4kB
[14:15] <mhr3> jibel, oh, i thought the machine got restarted since then
[14:15] <jibel> mhr3, I didn't you were working on it, but I can do it now if you wish
[14:15] <jibel> mhr3, should i?
[14:16] <mhr3> jibel, go ahead
[14:16] <mhr3> jibel, and it already kicked me off when we were talking
[14:16] <Cimi> mzanetti, moved to empty btw
[14:17] <mzanetti> Cimi: good. do you actually agree with my concerns?
[14:18] <mhr3> actually, i think my routing table got screwed up
[14:18] <Cimi> mzanetti, well the API is a good point
[14:18] <Cimi> mzanetti, still keeping background and thindivider in the basicmenu
[14:18] <Cimi> mzanetti, because we need them for theming
[14:19] <jibel> mhr3, done
[14:19] <mzanetti> Cimi: also, please create a test a quick test application (fullscreen ListView) with around 100 of your items, and check if its still scrolling smoothly on the glaaxy nexus
[14:20] <mzanetti> and then start adding/removing some dummy items in there and watch performance drop
[14:20] <mzanetti> just to get a feeling where the limit of items is
[14:21] <Cimi> mzanetti, once the sdk will give theming for listitems, all of that will be gone
[14:22] <didrocks> mhr3: sil2100: it seems no tests were rerun since the machine rebooted, should I rerun it?
[14:23] <dobey> where's the code that disables search on the 'home' [sic] lens in unity 8? does it require the "use libunity7" branch or something, to allow making scopes work again?
[14:24] <mfisch> mhall119: okay here
[14:26] <mhall119> mfisch: hey, I've not been able to compile your scope code
[14:26] <mhall119> I get: gcc: error: unrecognized command line option ‘-Wnounused-variable’
[14:26] <mhall119> make: *** [openclipart.o] Error 1
[14:26] <mfisch> mhall119: okay 1 sec
[14:26] <mhall119> if I comment that out in the .pro file, I get:
[14:26] <mhall119> In file included from openclipart.c:5:0:
[14:26] <mhall119> /usr/include/unity/unity/unity.h:1613:26: note: expected ‘struct UnityAbstractScope *’ but argument is of type ‘int *’
[14:26] <mfisch> mhall119: you're right
[14:26] <mhall119>  UnityScopeDBusConnector* unity_scope_dbus_connector_new (UnityAbstractScope* scope);
[14:26] <mhall119>                           ^
[14:26] <mhall119> make: *** [openclipart.o] Error 1
[14:27] <mfisch> mhall119: I see what I did wrong, I forgot to cleanup the old makefile
[14:27] <mfisch> mhall119: I'll fix it
[14:27] <mhall119> thanks
[14:30] <mfisch> mhall119: it looks like dpm and mhr3 already fixed it for me
[14:30] <mfisch> mhall119: lp:ubuntu-sdk-tutorials
[14:31] <mfisch> dpm: thanks to you and mhr3_ for fixing my compile issue, I forgot to remove the makefile after adding that flag
[14:32] <mhr3_> there was a problem with a flag? :)
[14:32] <mfisch> mhr3_: yeah, I was missing a -
[14:33] <mfisch> mhr3_: and thanks also for the other fixes ;)
[14:33] <didrocks> mhr3_: sil2100: I would take your silence as a "yes" :p
[14:34] <mfisch> mhr3_: I guess the activate function was not very useful
[14:34] <dpm> mfisch, no worries, we've now got a working scope \o/ - there are only two things that might need polishing: the installation of the .service file and the two fixmes you noted down (i.e. getting the icon to load and getting metadata). I'm not sure if the icon is that important, but if I look into the .service file installation, do you think you could look into adding that metadata?
[14:34] <mfisch> dpm: yeah, I can do that
[14:35] <didrocks> mterry: FYI, libusermetrics NEWed
[14:35] <mhr3_> didrocks, you asked something? sorry had little network trouble
[14:35] <mterry> didrocks, thanks!  I noticed it was in proposed
[14:35] <didrocks> mhr3_: no worry, just to ask if I should relaunch the tests
[14:35] <dpm> mfisch, perfect.
[14:35] <didrocks> mhr3_: I just did
[14:35] <didrocks> mterry: yw :)
[14:35] <mfisch> dpm: I assume the metadata is like what's used for music and what not, extra info basically?
[14:35] <mhr3_> didrocks, cool, yes pls, thanks :)
[14:35] <didrocks> mhr3_: so 1h15 for now to check how it goes
[14:36] <dpm> mfisch, yeah, that's my understanding from reading davidcalle's original python tutorial, but mhr3_ can probably better confirm
[14:38] <davidcalle> dpm, fisch, metadata is for everything relevant that doesn't fit in existing model fields (comment, icon, etc), like author, publication date. To have them available in the preview.
[14:38] <mhr3_> mfisch, yep, some masterscope define that all their children need to provide "isbn"; the other use case is for the scope to just attach whatever data it wants to the result, so it can be later used for generating a preview, or activation or something
[14:39] <dpm> didrocks, we're publishing a scopes tutorial on d.u.c., which requires this branch to land on the distro (https://code.launchpad.net/~mhr3/libunity/simple-scope) - mhr3_ thought he saw one of the distro build bots or whatever gets it into saucy processing it. Do you know more or less when this will be available in the archive?
[14:39] <dobey> where's the code that disables search on the 'home' [sic] lens in unity 8? does it require the "use libunity7" branch or something, to allow making scopes work again?
[14:40] <mhr3_> greyback, guess you'll know ^
[14:40] <dpm> davidcalle, btw, here's your tutorial code ported to C -> http://bazaar.launchpad.net/~ubuntu-sdk-tutorials-dev/ubuntu-sdk-tutorials/trunk/files/head:/unity-scopes/openclipart/ :-)
[14:40] <greyback> mhr3_: which question? dobey's?
[14:40] <davidcalle> dpm, fantastic! :)
[14:41] <mhr3_> greyback, yep
[14:41] <dpm> davidcalle, yeah, all thanks to mfisch and mhr3_ :)
[14:41] <didrocks> dpm: it should have just landed :)
[14:41] <greyback> Saviq: can you answer dobey's question? I've not followed the libunity story at all
[14:41] <Saviq> MacSlow, if you need help (or want me to handle one of the comments to parallelize) with the fixes to notifications, let me know
[14:42] <didrocks> dpm: hum, weird, I don't see it
[14:42] <mhall119> mfisch: still having a problem
[14:42] <mhall119> openclipart.c:82:5: warning: implicit declaration of function ‘unity_simple_scope_set_category_set’ [-Wimplicit-function-declaration] unity_simple_scope_set_category_set(scope,cats); ^
[14:42] <didrocks> https://launchpad.net/ubuntu/+source/libunity/7.0.4daily13.06.19-0ubuntu1
[14:42] <mhall119> make: *** [openclipart.o] Error 1
[14:42] <didrocks> dpm: it's not listed in the changelog, but it's in
[14:42] <Saviq> dobey, we didn't enable search in Home simply because it's not yet doing the right thing
[14:42] <dpm> mhall119, we've moved the branch and it should have those warnings fixed
[14:42] <dpm> mhall119, http://bazaar.launchpad.net/~ubuntu-sdk-tutorials-dev/ubuntu-sdk-tutorials/trunk/files/head:/unity-scopes/openclipart/
[14:42] <mhall119> dpm: that's from a clean branch of openclipart.c:82:5: warning: implicit declaration of function ‘unity_simple_scope_set_category_set’ [-Wimplicit-function-declaration] unity_simple_scope_set_category_set(scope,cats); ^
[14:42] <MacSlow> Saviq, ok
[14:42] <mhall119> lp:ubuntu-sdk-tutorials
[14:43] <mhall119> make: *** [openclipart.o] Error 1
[14:43] <Saviq> dobey, i.e. it's actually taking results from other scopes at the moment (or has them hardcoded)
[14:43] <dpm> mhall119, weird, I'm not getting any warnings
[14:43] <Saviq> dobey, after we move to smart scopes (today)
[14:43] <mfisch> mhall119: you need mhr3_'s latest libunity
[14:43] <mfisch> dpm: thats the error you get with the old libunity
[14:43] <dpm> ah, gotcha
[14:43] <Saviq> dobey, we'll move to using mock scopes for those (and enable search in Home)
[14:43] <Saviq> dobey, and then gradually replace with real scope backends
[14:44] <mfisch> mhall119: I can post debs for you, but I don't know if it will cause issues
[14:44] <dobey> Saviq: will it actually be enabled today?
[14:44] <didrocks> dpm: ah, it's listed in the changelog, I thought mhr3_ was writing it, it's james :)
[14:44] <mhall119> mfisch: where did you get it from?
[14:44] <mfisch> mhall119: I build it
[14:44] <dpm> mhall119, mfisch, from what didrocks is saying, the new libunity package with those changes already landed in the archive ^^
[14:44] <mfisch> mhall119: apt-get upgrade
[14:44] <Saviq> dobey, the search in Home? no, and not for some time yet, we need some changes across the stack to be able to go away from some hardcoded stuff in unity8
[14:45] <Saviq> dobey, but the switch to smart scopes - yes
[14:45] <dobey> Saviq: ok, then where is the code so that i can enable it in a local branch?
[14:45] <Saviq> dobey, DashHome.qml
[14:45] <greyback> mzanetti: platform-api, see android/hybris/default_application_manager.cpp. The process stop/continue is built into the focus handling code, so you'll need to patch out the kill() calls
[14:45] <Saviq> dobey, compare it to GenericLensView.qml (or GenericScopeView.qml from https://code.launchpad.net/~stolowski/unity/phablet-new-libunity/+merge/167717)
[14:45] <dobey> Saviq: so i roughly have to copy/paste some code from eg DashApps.qml over?
[14:46] <Saviq> dobey, yeah
[14:46] <mzanetti> greyback: awesome. thanks a bunch
[14:46] <dobey> ok, thanks
[14:46] <Saviq> dobey, just grep -i for search in there :)
[14:46] <dobey> yep, just did that
[14:46] <Saviq> dobey, or, if you want to get real home scope/lens results
[14:47] <Saviq> dobey, tweak LensDelegateMapper.qml
[14:47] <Saviq> dobey, so that Home doesn't get any special treatment
[14:47] <dobey> Saviq: i just want to be able to be at a point where i can actually start working on this stuff for 14.04 scopes that i'm supposed to start working on, so we can get the user research done on it :)
[14:47] <dobey> i can do fake results if i have to
[14:48] <Saviq> dobey, it's going to be much simpler after we've landed the smart scopes support today
[14:49] <dpm> davidcalle, one thing we noticed is that since we're shipping the openclipart scope by default, app developers will need to remove the existing scope to test the one in the tutorial. I was wondering if you had any suggestion for another service we could use instead of openclipart.org, which we could just swap easily in the code
[14:49] <dpm> mfisch, ^
[14:49] <mfisch> lol on easily swap in the code
[14:49] <dpm> :-)
[14:50] <mfisch> dpm: I dont see a new unity update on saucy
[14:50] <davidcalle> dpm, hmm... let me check.
[14:51] <dpm> mfisch, I think if it's not easy to swap we can live with getting them to remove the current scope for the tutorial purposes, but on the next update of the tutorial we should make it easier for folks and they shouldn't be messing around with the system
[14:51] <Saviq> mzanetti: could you do second eyes on https://code.launchpad.net/~unity-team/unity/8.new-libunity/+merge/167733 ?
[14:51] <dpm> I just hadn't realized that we were shipping openclipart until this morning when mhr3_ mentioned it to me
[14:52] <Saviq> mzanetti, it's scary initially (over 5k lines), but it's actually mostly s/lens/scope/g
[14:52] <mfisch> dpm: if davidcalle has another idea, I can switch us over, but then I probably wont finish Metadata today
[14:52] <Saviq> mzanetti, and a lot of red for removing People
[14:52] <mhr3_> dpm, the scope is 40% of the whole thing, and the rest is just rss parsing, so... yea swapping out what it talks to is the bigger part of it :)
[14:53] <Saviq> mzanetti, if it's too late / big for you for today, just say so
[14:53] <Saviq> mzanetti, otherwise here's how to get it on the device http://pastebin.ubuntu.com/5766051/
[14:54] <dpm> mfisch, I think metadata is more interesting to get in, so let's hear if davidcalle has got any suggestion, and if it's not a trivial swap (i.e. modifying the RSS processing) we can leave using something else than openclipart for another iteration of the tutorial
[14:54] <mfisch> dpm: the RSS processing is 75% direct from mrss and 25% a bit of a pain, although it will be much faster this time
[14:55] <mhall119> mfisch: dpm: that fixed it, thanks!
[14:55] <dpm> mhall119, cool, thanks for testing!
[14:55] <davidcalle> dpm, mfisch, no trivial swap suggestion (the closest RSS searchable feed I can think of right now are deviantart and googlenews and we ship both).
[14:55] <mhall119> davidcalle: will your little GUI client for seeing scope search results work on the new scopes API?
[14:56] <dpm> mhall119, it does, that's how we've been debugging it :)
[14:56] <dpm> mfisch, ok, in light of that comment ^, let's leave it as openclipart for now
[14:57] <mhall119> dpm: where can I get that gui client now?
[14:58] <dpm> mhall119, it's the libunity-tool binary, which comes from the libunity-tools package. I had it installed already, so perhaps you might not even need to install anything
[14:59] <mhall119> ah, yes, I have it, thanks
[14:59] <dpm> you can just run it as `libunity-tool -g` and if the scope is running, you should be able to pick it up from the drop down menu
[15:00] <mhall119> looking good
[15:01] <mhall119> so what's next to do, write the tutorial around this code?
[15:06] <mzanetti> Saviq: done with this: https://code.launchpad.net/~unity-team/unity-api/launcher/+merge/167586/
[15:06] <Saviq> mzanetti, cheers
[15:07] <mfisch> mhr3_: you said I needed to define a schema for metadata, correct?
[15:08] <mhr3_> mfisch, yep http://people.canonical.com/~mhr3/libunity7/unity/Unity.Schema.add_field.html
[15:08] <mfisch> mhr3_: ah a programmtaic schema, not a schema file
[15:09] <Saviq> mzanetti, and https://code.launchpad.net/~saviq/unity/8.update-pot/+merge/170380
[15:09] <mhr3_> mfisch, right, you should define the schema in the .scope file too though
[15:10] <mfisch> mhr3_: you saw my comment that the category icon didn't appear to work, any ideas?
[15:10] <mfisch> mhr3_: ok, will do
[15:10] <mhr3_> mfisch, but if you're defining only optional fields it's not "required"
[15:10] <mhr3_> mfisch, probably just wrong name
[15:10] <didrocks> Saviq: ok, your turn! let's try to look at this new component, mind giving me back the link with the rationale? :)
[15:10] <didrocks> Saviq: and if the upstream merger is wired?
[15:10] <mhr3_> mfisch, also i'm not sure how you tested it
[15:11] <mfisch> mhr3_: just ran my scope and didn't see the right icon
[15:11] <Saviq> didrocks, yes, it's wired (mmrazik said to look in phablet/shell.cfg)
[15:11] <mfisch> mhr3_: for the schema file, do we have an existing scope that uses one in the .scope file?
[15:11] <mhr3_> mfisch, if you added it as a top level scope and tried from home scope, you need a CategoryIcon= field in the .scope file iirc
[15:11] <Saviq> didrocks, and it's the notification backend that's used by unity8 to receive notifications from apps
[15:11] <mfisch> mhr3_: ah, thats probably it
[15:11] <mhr3_> mfisch, but it's probably the former
[15:12] <didrocks> Saviq: will apps dep on it?
[15:12] <didrocks> or just unity8?
[15:12] <Saviq> didrocks, no, just unity8
[15:12] <Saviq> didrocks, it's actually the first component to have "Provides: unity-notifications-impl, unity-notifications-impl-1"
[15:12] <didrocks> Saviq: so, it should be part of the unity8 stack, I guess?
[15:12] <Saviq> didrocks, so if you can look at that and the corresponding packaging change in https://code.launchpad.net/~macslow/unity/phone-shell-integration-notifications/+merge/168715
[15:13] <Saviq> didrocks, yes
[15:13] <didrocks> Saviq: ok, I'll give it a look and sanitize the packaging :)
[15:13] <didrocks> now looking at the MP
[15:13] <Saviq> didrocks, thanks
[15:15] <Saviq> mzanetti, did you see my request ↑↑↑ there about the scopes MP?
[15:15] <mzanetti> Saviq: hmm... no, only the .pot updated
[15:16] <mhr3_> Saviq, btw re the apps scope design doc, think we could go with category renderer = DYNAMIC, for the case where design says grid for < 10 results, carousel otherwise?
[15:16] <didrocks> Saviq: this build-deps on a virtual package is interesting, quite rare :)
[15:17] <Saviq> didrocks, in lp:unity-notifications? that's why you're looking at it, no? :)
[15:17] <didrocks> Saviq: no, the MP :)
[15:17] <didrocks> https://code.launchpad.net/~macslow/unity/phone-shell-integration-notifications/+merge/168715
[15:17] <Saviq> didrocks, is that build-dep?
[15:17] <didrocks> yep:
[15:17] <Saviq> didrocks, should be runtime...
[15:17] <didrocks> +         qtdeclarative5-unity-notifications-plugin | unity-notifications-impl,
[15:17] <didrocks>           qtdeclarative5-xmllistmodel-plugin,
[15:18] <didrocks>           qtubuntu,
[15:18] <didrocks> +         unity-notifications-impl-1,
[15:18] <didrocks> Saviq: my bad :p
[15:18]  * didrocks takes some coffee and back apparently…
[15:18] <Saviq> oh good
[15:18] <MacSlow> Saviq, didrocks: read...
[15:18] <didrocks> MacSlow: ignore me :p
[15:19] <Saviq> mhr3_, yeah, but it needs to be APPS_DYNAMIC or something
[15:19] <MacSlow> Saviq, another bit to fix in that brach ?
[15:19] <Saviq> MacSlow, no, it's good
[15:19] <MacSlow> Saviq, ok
[15:19] <didrocks> MacSlow: a little fix would be nice: https://code.launchpad.net/~macslow/unity/phone-shell-integration-notifications/+merge/168715/comments/379331
[15:19] <mhr3_> Saviq, right, i still want the category results type hint too
[15:19] <Saviq> mhr3_, ah then yeah
[15:19] <didrocks> MacSlow: just reorganizing the dep so that it's clear and close to the component providing it :)
[15:20] <MacSlow> didrocks, ok
[15:20] <Saviq> didrocks, so we're not anal about wrap-and-sort? :D
[15:20] <didrocks> Saviq: no, I prefer logical ordering TBH ;)
[15:21] <Saviq> mterry is ;d
[15:21] <didrocks> like for build-deps:
[15:21] <Saviq> fight!
[15:21] <didrocks> - build system/gcc
[15:21] <didrocks> - component build-deps
[15:21] <didrocks> - test components
 mzanetti: could you do second eyes on https://code.launchpad.net/~unity-team/unity/8.new-libunity/+merge/167733 ?
[15:21] <didrocks> Saviq: I'll just reject all NEW packages he will propose in the archive then! :p
 mzanetti, it's scary initially (over 5k lines), but it's actually mostly s/lens/scope/g
 mzanetti, and a lot of red for removing People
[15:21] <mterry> Saviq, I am  :)
 mzanetti, if it's too late / big for you for today, just say so
[15:21] <Saviq>  mzanetti, otherwise here's how to get it on the device http://pastebin.ubuntu.com/5766051/
[15:22] <didrocks> hum
[15:22] <didrocks> there is one binary package
[15:22] <didrocks> and an .install file?
[15:22] <mterry> didrocks, pfft!  You have wrap-and-sort as one of the standard tasks in daily-release cleanup  :)
[15:22] <tsdgeos> hmmm
[15:22] <tsdgeos> i've lost the hability to run ./run_on_device
[15:22] <didrocks> mterry: there are the components ordering as well that should be on the wiki page! :p
[15:22] <tsdgeos> it seems not to be running the build-deps
[15:22] <tsdgeos> ./build: 65: ./build: cmake: not found
[15:22] <tsdgeos> any idea why?
[15:23] <didrocks> mterry: you didn't look at this package, right? (the unity-notifications)
[15:23] <Saviq> tsdgeos, try installing the unity8-build-deps-dep package
[15:23] <Saviq> tsdgeos, and go for `apt-get -f install`
[15:23] <Saviq> tsdgeos, the package is in ~phablet
[15:23] <mterry> didrocks, no
[15:23] <didrocks> mterry: ok good, I don't have to blame you then! ;)
[15:24] <Saviq> didrocks, the only binary package has a different name than the source package
[15:24] <seb128> mterry, hey, I pushed an updated unity-greeter logo, nicely spotted ;-)
[15:24] <Saviq> didrocks, I think I've had issues with that without the .install file
[15:24] <mterry> seb128, cool, will look at it again
[15:24]  * Saviq tries
[15:24] <didrocks> Saviq: yeah, not a blocker, when you have one binary package, it's set at DESTDIR=
[15:24] <seb128> mterry, is that known that make check segfaults somewhere in the xvfb-run command under bzr bd?
[15:24] <tsdgeos> Saviq: no such package is known to my phone
[15:24] <didrocks> Saviq: I'm trying as well :)
[15:24] <seb128> mterry, it doesn't segfault when I run it by hand though
[15:24] <mterry> seb128, hrm...  no?
[15:24] <Saviq> tsdgeos, it's a .deb file in ~phablet
[15:24] <tsdgeos> ah
[15:24] <mterry> seb128, yeah I usually run by hand or in chroot, not bd
[15:25] <seb128> mterry, I will not bother debugging since it runs by hand, something in the tools...
[15:25] <didrocks> Saviq: not a biggie but test/notificationtest.cpp doesn't have any copyright, is it ours?
[15:25] <Saviq> didrocks, yes it is
[15:25] <didrocks> Saviq: if so, no clear need to fix it, the global license and copyright applies
[15:25] <Cimi> mzanetti, I created a bool 'playing' property for the mediaplayerMenu
[15:26] <Cimi> when is false, I show play, pause otherwise
[15:26] <didrocks> no COPYING file, fixing
[15:26] <Cimi> (missing pause artwork)
[15:27] <Saviq> didrocks, built fine without the .install file
[15:27] <didrocks> Saviq: yeah, confirmed here, I'm committing it
[15:27] <didrocks> Saviq: will propose you a MP in the end with all the fixed
[15:27] <mzanetti> Cimi: sounds fine on a first/simple tought
[15:27] <didrocks> fixes*
[15:28] <mzanetti> Cimi: not sure where this component will go, but think a bit ahead. Will this be extended in the future? In that case I'd probably even define some sort of enum
[15:28] <mzanetti> Cimi: if you say play and pause is all I need, the bool should be ok
[15:28] <Cimi> mzanetti, I'll add complexity if it's needed
[15:28] <Cimi> at the moment I cannot think of something differnt
[15:28] <Cimi> play/pause and signals
[15:29] <mzanetti> Cimi: sure.
[15:29] <mfisch> dpm / mhall119 pushed a fix for the category icon
[15:29] <Saviq> mzanetti, you put a filter on me didn't you :P
[15:29] <dpm> mfisch, cool thanks!
[15:29] <mzanetti> no. I noted your messages
[15:29] <mzanetti> Saviq: ^
[15:29] <mzanetti> :P
[15:30] <mzanetti> Cimi: what I mean is with defining public API. once people are using your bool, you can't easily change it to an enum...
[15:30] <Saviq> mzanetti, so no filter, just ignore? ;P
[15:30] <mzanetti> Saviq: yeah
[15:31] <mzanetti> Saviq: I don't know much about the .po changes :/
[15:31] <Cimi> mzanetti, I see
[15:31] <Cimi> mzanetti, cannot see other usages
[15:31] <mzanetti> Saviq: is that just some script that runs, does the update, and you comitted that?
[15:31] <Saviq> mzanetti, yeah, that's make -C builddir po/unity8.pot
[15:32] <mzanetti> Cimi: fine with me... Just trying to help you understand my thoughts
[15:32] <Saviq> mzanetti, should be ran every time we change translatables
[15:32] <mzanetti> Cimi: if you think play/pause will be enough forever, keep the bool
[15:32] <Cimi> mzanetti, it's as in the desktop... so maybe yes
[15:32] <mzanetti> Saviq: ack
[15:36] <didrocks> Saviq: ok, the package is simple and I had few things to fix: https://code.launchpad.net/~didrocks/unity-notifications/packaging-fixes/+merge/170387
[15:36] <Saviq> didrocks, on it
[15:37] <didrocks> Saviq: are there any integration tests we can run?
[15:38] <Saviq> didrocks, there's a set of regression tests there
[15:38] <Saviq> didrocks, in examples
[15:38] <didrocks> Saviq: are they autopilot tests?
[15:38] <Saviq> didrocks, no, they're just .py scripts that push the notifications
[15:39] <Saviq> didrocks, so there's work needed
[15:39] <Saviq> didrocks, to make them real integration tests
[15:39] <didrocks> Saviq: would be interesting to change them to autopilot tests (or just even triggered by them), do you think some people may jump on that?
[15:39] <didrocks> yep :)
[15:39] <Saviq> didrocks, yeah, it's Satoris's project
[15:39] <Saviq> didrocks, I'll let him know
[15:40] <didrocks> Saviq: thanks! once my package changes merged, I'm happy to add it to daily release and NEW it right now *if* the autopilot tests are coming :)
[15:40] <didrocks> and think about pinging us when they arrive so that we can run them :)
[15:40] <Saviq> didrocks, yup, will do
[15:42] <mfisch> dpm: after I add this metadata, I'll need to figure out where to free the hashtable that I'm using
[15:42] <mfisch> dpm: we can always do a rev 1.1 of this demo if we find issues like this
[15:45] <didrocks> fginther: mmrazik: mind having a look? https://code.launchpad.net/~didrocks/cupstream2distro-config/move-unity-notifications/+merge/170389
[15:45] <dpm> mfisch, ack. If you think it you might not be able to look at the metadata thing today, we can just drop it for this 1.0 version. The important thing is that we can get something working solidly for tomorrow.
[15:45] <didrocks> as I'm not sure for the upstream merger :)
[15:45] <mfisch> dpm: okay
[15:47] <didrocks> Saviq: no global approval, is it on purpose?
[15:47] <Saviq> didrocks, I'm community for that project...
[15:47] <didrocks> oh :)
[15:48] <Saviq> didrocks, just trying to sort it out
[15:48] <Saviq> tedg, can I ask you to move lp:unity-notifications to lp:~unity-api-team/unity-notifications/trunk
[15:48] <didrocks> Saviq: yeah, indeed, the perms are wrong
[15:48] <didrocks> https://code.launchpad.net/~jpakkane/unity-notifications/trunk
[15:48] <Saviq> tedg, and add ~pspmteam to ~unity-api-team so that Jenkins can do stuff?
[15:48] <didrocks> we can't even have the upstream merger with that ^
[15:49] <Saviq> didrocks, yeah
[15:49] <didrocks> Saviq: one sec, I can do it (the move and renaming)
[15:49] <Saviq> didrocks, oh cool
[15:50] <Saviq> tedg, ignore
[15:50] <didrocks> Saviq: let's put that under the ~unity-team umbrella?
[15:50] <didrocks> or ~unity-api-team?
[15:50] <Saviq> didrocks, ~unity-api-team, I think
[15:50] <didrocks> fine by me :)
[15:50] <didrocks> ah
[15:50] <didrocks> I don't have this ~unity-api-team creds though
[15:50] <didrocks> weird, it seems pspmteam isn't the owner of it?
[15:50] <didrocks> (should be fixed)
[15:51] <fginther> didrocks, otp, will look after a bit
[15:51] <didrocks> yeah, ted is the owner
[15:51] <didrocks> so, first step, getting that in line with others teams, making pspmteam the owner
[15:52] <didrocks> and then, we can change trunk
[15:53] <didrocks> Saviq: if things are not fixed before EOD, we can at least have it releasing tomorrow morning :)
[16:00] <dednick> Saviq: the LightDM mock data providers don't seem to be working properly
[16:01] <dednick> works with the demo, but doesnt change with different LD_LIBRARY_PATH like it's supposed to.
[16:04] <Saviq> didrocks, yeah, I pushed it to the PPA manually for now
[16:04] <mzanetti> Saviq: removes all my beautiful people lens code =(
[16:05] <Saviq> mzanetti, there's a lot of my code there, too
[16:05] <mzanetti> :D
[16:05] <Saviq> mzanetti, it might come back yet
[16:05] <Saviq> mzanetti, in one form or another
[16:06] <Saviq> mzanetti, what people will miss most I think is the favorites in Home
[16:06] <Saviq> mzanetti, and that will come back pretty quickly
[16:06] <mzanetti> Saviq: hm... tbh I didn't use the home lens AT ALL so far
[16:06] <mzanetti> Saviq: only people and apps lens
[16:07] <mzanetti> but it hasn't been very functional either so far
[16:07] <Saviq> mzanetti, the people lens was really a contacts app, not even reachable much quicker
[16:07] <Saviq> bar the launch time
[16:07] <didrocks> mhr3_: for how long are you still around? I can again tackling the tests
[16:07] <didrocks> mhr3_: and hope for a blocking situation
[16:16] <mhr3_> didrocks, i have a feeling this isn't working, having a script that could be run on the hanging system (or even non hanging before the timeout kills it) might be better idea
[16:16] <mhr3_> the question is what to put in the script
[16:17] <didrocks> mhr3_: yeah, I have no idea TBH :/
[16:17] <fginther> didrocks, regarding move-unity-notifications... You mention head/misc in your MP comments, but unity-notifications was added to head/mir.cfg.  Was that intentional?
[16:18] <didrocks> fginther: typo for mir :p
[16:18] <mhr3_> didrocks, free, ps aux, and a bunch of dbus calls comes to mind
[16:19] <mhr3_> other than that... guess we'd know after we'd get the first results :)
[16:19] <didrocks> mhr3_: I propose that we redo the same tomorrow, just in case we can trick it
[16:20] <mhr3_> didrocks, sure, i'll try to prepare such script anyway, will be useful for me either way
[16:22] <didrocks> mhr3_: yep :)
[16:26] <fginther> sergiusens, can you review (for phablet-land change): https://code.launchpad.net/~didrocks/cupstream2distro-config/move-unity-notifications/+merge/170389 ?
[16:27] <didrocks> fginther: I think the goal is to remove the dput in the ppa, it was just a today's workaround, time to review and fix the package (anyway, there is still the team perm issue to fix)
[16:57] <didrocks> fginther: fixed, I think we don't need to wait on sergiusens (on holidays) as this will be pushed to distro
[16:57] <didrocks> fginther: so no need for the phablet-team ppa
[17:00] <Saviq> didrocks, so is there a unity update coming to S today?
[17:01] <didrocks> Saviq: as promissed, it's in :)
[17:01] <didrocks> https://launchpad.net/ubuntu/+source/unity
[17:01] <Saviq> didrocks, nice
[17:02] <mterry> racarr, in your platform-api mir-with-packaging branch, you are installing the .so symlink for mirclient/mirserver in the library package instead of the -dev package, FYI
[17:11] <mfisch> mhr3_: you still around?
[17:11] <mhr3_> mfisch, yea
[17:11] <mfisch> mhr3_: the metadata is just a glib hashtable right?
[17:11] <mhr3_> mfisch, right, keys are string, values GVariants
[17:12] <mfisch> mhr3_: ah, I had string/string which is probably the issue
[17:12] <mfisch> Gvariant, my old nemesis, we meet again
[17:13] <mhr3_> mfisch, re mem management there, in C this should work:
[17:15] <mhr3_> GHashTable *dict = g_hash_table_new (g_str_hash, g_str_equal); g_hash_table_insert (dict, "extra-field", g_variant_new_string ("foo")); result.metadata = dict; ..add_result (..., &result); g_hash_table_unref (dict);
[17:15] <mfisch> so I can unref it before returning the results?
[17:15] <mfisch> does unity make a copy?
[17:15] <mhr3_> yep
[17:15] <mfisch> or wait the unref just tells glib to deal with it
[17:15] <mfisch> ok
[17:15] <mfisch> thanks
[17:16] <mfisch> I have the code done, need to test real quick
[17:16] <mhr3_> mfisch, my primary point though was the floatingness of GVariant
[17:16] <mfisch> yep
[17:16] <mfisch> I used them a lot in powerd last month
[17:16] <mhr3_> yea, they're "fun"
[17:17] <mhr3_> took me about a year to learn all the nooks and crannies of the mem management with them
[17:17] <mfisch> as you can see I get random tasks like this one and I always learn new stuff
[17:17] <mhr3_> floatingness is an awesome concept that just makes everything complicated while pretending to make it easy :P
[17:18] <seb128> mterry, hey again, unity-greeter is not on daily landing right? should I just make dist a tarball and upload that version with the new logo?
[17:18] <mterry> racarr, and mirclient is missing mir_egl_mesa_display_is_valid symbol?
[17:18] <racarr> mterry: Ugh riccm was mentioning this last night
[17:18] <racarr> mterry: It's almot certainly not but something has gone wrong with our switched so names
[17:18] <mterry> seb128, oh, I was going to release, doing distcheck now...
[17:18] <seb128> mterry, less work for me? +1 :p
[17:18] <racarr> mterry: First, can you make sure everything is update to date rom mir-team PPA? We had some issues with mesa
[17:19] <mhr3_> mfisch, i noticed, ondra mentioned that you're mostly ufa guy
[17:19] <mterry> racarr, I did
[17:19] <mterry> racarr, libEGL.so is complaining about that missing symbol
[17:19] <mterry> racarr, and it links to two mir libraries:
[17:19] <mterry> 	libmirclient.so.0 => /usr/lib/libmirclient.so.0 (0x40176000)
[17:19] <mterry> 	libmirprotobuf.so.0 => /usr/lib/libmirprotobuf.so.0 (0x404a8000)
[17:19] <mfisch> mhr3_: our team is pretty random, I've done powerd, a thin client project, ufa, nexus7, checkbox tests
[17:20] <mfisch> mhr3_: we're the A Team, when work needs to be done, we're there ;)
[17:20] <mterry> racarr, of which I have 0.0.3bzr748saucy0 and 0.0.4bzr757saucy0 respectively
[17:20] <racarr> mterry: Oh this is interesting...
[17:20] <mfisch> mhr3_: okay, its not complaining anymore with the gvariant
[17:20] <racarr> mterry: Ok the problem is we are using
[17:20] <racarr> mesa to build things, I guess because it's hard to link against android gl from the build environment
[17:20] <racarr> but mesa isn't actually used on phone, and in particular
[17:20] <mhr3_> mfisch, at least you're not bored with always the same thing ;)
[17:21] <mfisch> mhr3_: never bored!
[17:21] <racarr> mir isn't built with the mesa_display_is_valid stuff on PLATFORM=android
[17:21] <mfisch> mhr3_: but I occassionally sign up for stuff like this and then stare at a blank C file and say "what was i thinking"
[17:21] <racarr> So, Mesa rom the mir PPA links against mirclient and expects
[17:21] <racarr> a mirclient compiled with the mesa stuff
[17:21] <racarr> mterry: I think for now, you need to use
[17:21] <racarr> the archive mesa on the phone
[17:22] <mhr3_> mfisch, heh, isn't powerd in C as well?
[17:22] <mfisch> mhr3_: yeah, it was C++ but we killed that ;)
[17:22] <mterry> racarr, will try
[17:23] <racarr> mterry: It's amazing what the morning does
[17:23] <racarr> ricmm mentioned this to me last night at like 11:30pm my time
[17:24] <racarr> and my memory of it is like "huh, symbols, what?"
[17:32] <mterry> racarr, seems to have worked
[17:33] <mterry> racarr, mind if I modify your sketchpad instructions to just use debuild on the packaging branches?
[17:33] <mterry> manually installing seems odd
[17:39] <racarr> mterry: No please do
[17:43] <mterry> racarr, building your qtubuntu branch, I get: /home/phablet/tmp/qtu-pack/src/modules/application/application_manager.cc:280: undefined reference to `ubuntu_ui_install_task_controller'
[17:45] <racarr> mterry: Woah that sound unfamiliar
[17:45] <racarr> mterry: Anyway, you can build from
[17:45] <racarr> src/platforms
[17:46] <racarr> and just qmake "CONFIG+=mirclient" "CONFIG+=mirserver" there
[17:46] <racarr> mterry: Though...it should build. that should be in your hybris
[17:46] <racarr> app API and it should
[17:46] <racarr> link against that
[17:47] <mterry> that's a hybris thing?  OK, let me see why it can't find it
[17:47] <racarr> yeah, it's from the hybris libubuntu_application_api
[17:47] <racarr> just ubuntu_application_api that is (mirclient andmirserver have suffixes)
[17:48] <racarr> the applictaion module doesn't work yet on mir but you should be able to either build from src/platforms or just build it against your hybris app API (tested this on the phone last night)
[17:48] <mterry> racarr, libhybris 0.1.0+git20130606+c5d897a-0ubuntu2 in saucy doesn't have ubuntu_ui_install_task_controller in its source
[17:48] <racarr> oh you probably want CONFIG+=hybris too for qtubuntu
[17:48] <racarr> mterry: ok...maybe something happened when platform-api landed
[17:48] <racarr> and no one told me XD
[17:48] <racarr> let me look at what i going on
[17:51] <racarr> mterry: Oh sorry, it's not in
[17:51] <racarr> libhybris its in
[17:51] <racarr> oh my god network latency
[17:51] <racarr> mterry: it's in, platform-api
[17:51] <racarr> but I meant, it's only in the
[17:51] <racarr> hybris backend for platform API
[17:51] <racarr> i.e. libubuntu_application_api.so
[17:52] <racarr> which should be what the application module is linking against
[17:52] <racarr> maybe when you built platform-API you didnt update the hybris one and something is out of sync?
[17:52] <racarr>  I dont know the history of this unction
[17:54] <mterry> racarr, I'll investigate
[17:55] <mterry> racarr, ubuntu_ui_install_task_controller is also not in your platform-api packaging branch anywhere
[17:58] <racarr> mterry: agh sorry packaging branch needed a
[17:58] <racarr> trunk merge
[17:58] <racarr> hould have r128 now
[18:00]  * mterry rubs hands in anticipation of build finishing
[18:01] <racarr> :)
[18:01] <mterry> racarr, hmm, this now lost the mirclient and mirserver packages?
[18:04] <racarr> mterry: Did you purge the ppa?
[18:04] <racarr> or do they depend on mesa mistakenly...
[18:05] <mterry> racarr, no, your updated platform-api packaging branch no longer builds mir packages
[18:05] <mterry> racarr, it looks more like trunk
[18:05] <racarr> err
[18:05] <racarr> mterry: Grr, XD
[18:05] <racarr> sorry
[18:06] <racarr> I am trying to do two things at once which never goes well
[18:06] <mterry> :)
[18:07] <racarr> mterry: Ok, if you pull again (still r128, there is an overwrite)
[18:07] <racarr> it should be better
[18:07] <racarr> my phone is currently tied up in building other things XD
[18:07] <mterry> I'll be your test :)
[18:08] <mterry> racarr, again, not sure if you saw my message before, but your platform-api branch should move the bare .so symlinks for mirclient/mirserver to the -dev package
[18:09] <racarr> mterry: What's the pattern to do that?
[18:09] <racarr> I don't really have much experience at all making packages
[18:10] <mterry> racarr, switch the library packages to "...so.*" instead of "...so*"
[18:10] <mterry> racarr, and make the -dev.install package be something like "..._api*.so"
[18:10] <racarr> why _api* instead of *?
[18:10] <mfisch> mhall119: ping
[18:10] <mterry> that is, make sure that the library packages have a dot after the so and the dev accepts all bare so symlinks
[18:11] <mterry> racarr, you could do * too.  I thought you already had _api.so (I was just inserting a *)
[18:11] <mterry> racarr, the important thing is that the ending is just ".so"
[18:11] <racarr> mterry: Ok! thanks, will fix it up soon
[18:12] <mhall119> mfisch: pong
[18:12] <mterry> ok, that built, now building qtubuntu against it
[18:12] <mfisch> mhall119: is dpm going to write the guide tomorrow?
[18:12] <racarr> huzzah
[18:12] <mfisch> I geuss dpm might still be here actually
[18:12] <mhall119> mfisch: the tutorial?
[18:12] <mfisch> yeah
[18:12] <dpm> mfisch, yes and yes
[18:13] <mfisch> dpm: I have all the theory down on the metadata, it's just segfaulting inside unity now
[18:13] <dpm> mfisch, oops
[18:13] <mfisch> bet I know why too
[18:13] <mfisch> err hope i mean
[18:15] <dpm> mfisch, I've pushed a couple of changes to the .pro file. Now you should be able to run 'sudo make install' to install the scope and test it in the dash 'make uninstall' should work too
[18:16] <mfisch> dpm: cool
[18:16] <mfisch> dpm: is mhall119 testing changes as they land?
[18:16] <dpm> mfisch, I think it's best if you ping him whenever there are changes to test
[18:17] <mterry> racarr, yeah that did the trick for qtubuntu
[18:18] <mhall119> mfisch: I'll test whenever you tell me to
[18:18] <mfisch> dpm: anyone here currently who could assist with this segfault? it's inside libunity
[18:18] <racarr> mterry: hurrah!
[18:18] <mfisch> mhall119: maybe test dpm's install stuff and make sure the category icon is working, I hope to have the metadata changes today and i'll let you know then
[18:18] <racarr> Sorry it's such a mess atm :( it should be in parallel CI in a day or two
[18:19] <mhall119> mfisch: ok
[18:20] <mterry> racarr, hmm, now running unity isn't working.  Just exits with 1.  What package provides mir_demo_server?
[18:20] <mterry> I don't seem to have it
[18:20] <racarr> mterry: mir-demos, but you don't need it
[18:20] <racarr> unity itself is the server binary
[18:20] <racarr> you should be able to run unity like
[18:20] <dpm> mfisch, I don't know if there's anyone who can help, it might be worth asking, though. mhr3 and pstolowski have already EOD'd
[18:20] <racarr>  ./run -i -m -f
[18:21] <dpm> anyone able to help mfisch with a scope that's segfaulting in unity?
[18:21] <mterry> racarr, well, I'm on device, so I'm not using -f.  But -i -m just returns with status 1
[18:21] <racarr> mterry: No you need -f or it will try and load
[18:21] <racarr> the old application manager plugin
[18:21] <racarr> and segfault I think
[18:21] <mterry> racarr, well, same result either way
[18:21] <mfisch> dpm: let me email them
[18:22] <racarr> mterry: Ok, so probably the script is hiding whatever is happening so
[18:22] <racarr> mterry: Can you
[18:22] <racarr> export QML2_IMPORT_PATH=$PWD/builddir/tests/mocks:$PWD/builddir/plugins
[18:22] <racarr> for -f
[18:22] <mterry> racarr, says fd/0 no such file or directory on device
[18:22] <mterry> or rather /proc/.../fd/0
[18:23] <racarr> and export
[18:23] <racarr> QT_QPA_PLATFORM=ubuntumirserver
[18:23] <racarr> then just try running qml-phone-shell
[18:23] <racarr> ?
[18:23] <mterry> ok, will try
[18:24] <mterry> segfault
[18:24] <racarr> mterry: bt?
[18:25]  * mterry installs gdb
[18:25] <racarr> mterry: Are you having fun yet
[18:25] <racarr> ;)
[18:27] <mterry> racarr, corrupted stack in /usr/lib/arm-linux-gnueabihf/libhybris-common.so.1...
[18:28] <mhall119> mfisch: which install stuff did you want me to test?
[18:29] <mfisch> mhall119: <dpm> mfisch, I've pushed a couple of changes to the .pro file. Now you should be able to run 'sudo make install' to install the scope and test it in the dash 'make uninstall' should work too
[18:29] <mhall119> ah, ok
[18:29] <racarr> mterry: No symbols?
[18:29] <mterry> racarr, nope, stack is bogus
[18:30] <racarr> mterry: Hmm the only time I saw something like that was
[18:30] <racarr> when it was trying to load the real app manager plugin
[18:31] <mhall119> mfisch: do I need to restart unity still for it to show up?
[18:31] <racarr> mterry: Oh are you running it as root?
[18:31] <racarr> mterry: Is surface flinger stopped?
[18:31] <mterry> racarr, as root, with surface flinger stopped.  let me double confirm sf is stopped
[18:32] <racarr> it loves to come back XD
[18:32] <dpm> mhall119, pkill -f unity-scope-home should do
[18:32] <racarr> I had to move the binary, ogra knows some incantation for stopping it from starting
[18:32] <mterry> racarr, yar, stopped, as root
[18:32] <mterry> racarr, oh
[18:32] <mterry> racarr, I thought just running 'stop' outside of chroot was enough
[18:32] <dpm> mfisch, where can the icon be seen? If the openclipart scope is a child of the graphics master scope, the openclipart scope will be shown as a filter in the home scope, right? At least that's what mhr3 mentioned, and I couldn't see the icon anywhere while I was testing from the dash
[18:32] <racarr> mterry: Oh wait are you on non flipped?
[18:33] <mterry> racarr, uh, I'm on the default image.  So yes?
[18:33] <racarr> oh hmm
[18:33] <racarr> I haven't tested it on non flipped saucy phone
[18:33] <mhall119> dpm: thanks
[18:33] <mterry> oh whoops, didn't realize flipped was a req
[18:33] <racarr> well
[18:33] <racarr> I'm not ure
[18:33] <racarr> why it would be
[18:33] <racarr> but it's something!
[18:33] <racarr> *thinks*
[18:34] <mterry> racarr, I'd prefer to try other things if you can think of them to do, before re-flashing
[18:34] <mterry> racarr, is there a good way to get a log from qml-phone-shell?
[18:35] <racarr> mterry: not a great log! besides anything it prints when you run it
[18:35] <mterry> racarr, also, you haven't merged your unity branch from trunk for a while, if we're still using the binary name qml-phone-shell.  :)
[18:35] <racarr> mterry: First, let's just rule out one big
[18:35] <racarr> bit
[18:35] <racarr> http://unity.ubuntu.com/mir/using_mir_on_android.html
[18:35] <racarr> and make sure mir itself runs
[18:35] <racarr> wiith some demos
[18:35] <mterry> fair
[18:35] <racarr> mterry: No...it needs a merge :( I tried to do it yesterday
[18:35] <racarr> but they deleted
[18:36] <racarr> their history
[18:36] <racarr> so I have to manually apply it all
[18:36] <racarr> and I need to find time to do so
[18:36] <mterry> racarr, ah yeah, you haven't rebased on 8.0
[18:36] <racarr> you are using lp:~unity-team/unity/phablet-integrate-mir right?
[18:36] <mterry> racarr, mir_demo_server segfaults
[18:36] <racarr> not phablet-tuesday (dead)
[18:36] <mterry> correct
[18:36] <racarr> oh.
[18:36] <racarr> ok that's helpful to know
[18:36] <racarr> can we make sure there are debug symbols for mir then see
[18:36] <racarr> if we can get anything out of the stack trace
[18:36] <racarr> which device?
[18:39] <mterry> k, nexus7
[18:39] <racarr> oh
[18:39] <racarr> um
[18:39] <racarr> I'm not sure the nexus 7 works :(
[18:40] <mterry> racarr, guh
[18:40] <racarr> there have always been hybris issues
[18:40] <racarr> I think there was some hope that the new
[18:40] <mterry> racarr, I thought that had been resolved
[18:40] <racarr> hybris upstream might fix it but I'm
[18:40] <racarr> well
[18:40] <racarr> that's what I am trying to
[18:40] <racarr> discover...:)
[18:40] <mterry> racarr, saucy has relatively recent libhybris
[18:40] <racarr> lets get a BT
[18:40] <racarr> mm
[18:40] <racarr> but, I tried backporting an upstream libhybris myelf a month or so ago
[18:40] <racarr> and also ran in to crashes
[18:40] <racarr> so I am not sure if it really fixes it
[18:41] <racarr> (it's also possible that I screwed that process up and it does fix it)
[18:41] <mterry> racarr, OK, let me enable dbgsym packages and get the one for mir-demos
[18:41] <racarr> Thanks :)
[18:41] <racarr> ill start updating my nexus 7 to saucy
[18:41] <mterry> racarr, an upstream libhybris a month ago didn't have a patch we needed for nexus7
[18:41] <racarr> just for more data points
[18:41] <racarr> mterry: Well, I pulled from this branch
[18:41] <mfisch> dpm: let me post a pic
[18:41] <mterry> racarr, so not saying there aren't other problems, but that a month ago wasn't sufficient either
[18:41] <racarr> that some guy had that was supposed to have
[18:41] <racarr> the fixes.
[18:42] <racarr> about
[18:42] <mterry> racarr, ah ok.  pull49 or some such
[18:42] <racarr> shared memory mutexes? or some such
[18:42] <mterry> yup
[18:42] <mfisch> dpm: see the little tiny icon by the word Openclipart?  http://imgur.com/3c9fMdW
[18:42] <mterry> racarr, I pulled that and got mir working for a whole day
[18:42] <racarr> oh
[18:42] <racarr> good work XD
[18:42] <mterry> racarr, but then I did a system update on the machine and it stopped working, even with the hybris fix
[18:42] <mterry> racarr, never figured it out
[18:43] <mterry> racarr, but there was one brief shining moment
[18:43] <dpm> mfisch, ah, yeah, I can see it now, thanks for the clarification!
[18:43] <racarr> mterry: ...and then...ITS GONE
[18:43] <mfisch> charles: ping
[18:44] <dpm> mfisch, regarding the metadata, mhr3__ mentioned something about creating a schema for it when defining the scope. I'm not sure if that helps with your segfault, but I thought I'd mention it
[18:44] <mhr3__> mfisch, you shouldn't g_variant_unref
[18:46] <mhr3__> mfisch, oh, i see the bug
[18:47] <mfisch> dpm: I added the schema, and it didnt help
[18:47] <mfisch> mhr3__: perfect
[18:47] <mterry> racarr, guh, ddebs don't seem to be enabled for ports?  I'll rebuild mir myself I guess
[18:47] <dpm> ok, it seems mhr3__ comes to the rescue :)
[18:48] <mfisch> mhr3__: I had the unref commented out as an experiment
[18:48] <mfisch> I'll trade a memleak for functionality anyday! ;)
[18:49] <racarr> mterry: Ok.
[18:49] <mhr3__> mfisch, as a workaround for the crash, you'll need to ref_sink the info hint and unref it after add_info_hint()
[18:49] <racarr> cmake -DBoost_COMPILER=-gcc -DMIR_PLATFORM=android ..
[18:49] <racarr> should be all you need
[18:49] <mfisch> mhr3__: okay, is the underlying issue in libunity?
[18:49] <mhr3__> yea
[18:49] <mfisch> ok
[18:54] <mfisch> mhr3__: dont unref the gvariant in all cases or only when I use the new_hint_with_variant?
[18:54] <mhr3__> mfisch, the one you get from hash_table_lookup
[18:55] <mfisch> ok
[18:58] <mhr3__> mfisch, just for you - https://code.launchpad.net/~mhr3/libunity/floating-fixes/+merge/170421
[18:58] <mfisch> mhr3__: I have metadata, yay
[18:58] <mfisch> mhr3__: okay, I'll try that too, in a minute
[18:58] <mhr3__> mfisch, with that you won't need the ref_sink workaround
[18:59] <mfisch> yep
[18:59] <mfisch> will it land before this demo code gets released?
[18:59] <mhr3> mfisch, not overly likely
[19:00] <mhr3> mfisch, but if you approve it after you try it, you'll help it :)
[19:00] <mfisch> ok
[19:02] <mfisch> mhr3: building it now
[19:06] <mfisch> dpm-afk/ mhr3 : http://i.imgur.com/0qnoCTl.png
[19:07] <mhr3> coolio
[19:09] <mfisch> mhr3: when I try your fix, I no longer segfault, but when I comment out my ref/unref lines, I dont get a preview image
[19:09] <mfisch> I built on the old branch though, let me pull a clean libunity
[19:09] <mhr3> mfisch, ehm, nothing change re images though
[19:09] <mhr3> changed*
[19:10] <mfisch> let me repro and make sure its not some odd network issue
[19:11] <mfisch> hmm it failed this time too
[19:15] <mfisch> mhr3: well its not your fault anyway
[19:15] <mfisch> "Unable to load icon <url> at size -1x-1: The name :1.84 was not provided by any service files.
[19:15] <mfisch> probably my slow vm
[19:16] <mhr3> hm, good ol gvfsd-http crashing
[19:16] <mfisch> i'll stick that in my nmfp bucket
[19:16] <mhr3> nmfp?
[19:17] <mfisch> not my, uh fine, problem
[19:17] <mhr3> :)
[19:17] <mfisch> or whatever f word you feel like using ;0
[19:18] <mfisch> mhall119: ping
[19:18] <mhall119> mfisch: pong
[19:18] <mfisch> mhall119: can you search for "dog" and see if you have issues getting the preview image to work?
[19:19] <Saviq> mhr3, no way now to pass an argument to a scope ran by unity-scope-runner?
[19:20] <mhr3> Saviq, oh right, we changed it
[19:20] <Saviq> mhr3, indeed ;)
[19:20] <mhr3> Saviq, it took just one scope module previously, but now it takes whatever number of them
[19:21] <Saviq> mhr3, yeah, will need to redo the mock scope
[19:22] <mhr3> Saviq, yea, sorry, forgot about mock using that
[19:22] <mhall119> mfisch: works okay for me
[19:22] <mhr3> Saviq, but ultimately we want the modules
[19:22] <mfisch> mhall119: thanks
[19:22] <mhall119> any specific result that was giving you a problem?
[19:22] <mfisch> mhall119: the 2nd one and 3rd one
[19:22] <mfisch> the collie one
[19:22] <Saviq> mhr3, yeah I get it, will build mock modules then
[19:23] <mhr3> Saviq, so theoretically the module should do some import magic to import the mock scope and them return the actual scope
[19:25] <mhall119> mfisch: it's hard to see, being dark lines on a transparent background, but it's there
[19:25] <mfisch> mhall119: thanks
[19:25] <mhall119> np
[19:26] <mfisch> mhr3: +1 on your fix, will comment
[19:38] <mfisch> mhall119: please pull the latest copy and see if the Hints are working
[19:38]  * mhall119 bzr pulls
[19:44] <mfisch> mhall119: probably should nuke the makefile and start clean
[19:50] <mhall119> mfisch: works perfectly
[19:52] <charles> mfisch: oh, I didn't see your ping earlier :(
[19:52] <charles> mfisch: pong
[19:52] <mfisch> charles: no worries, it was a bug in libunity, I was going to ask a scope question
[19:54] <mhall119> mfisch: do we not have constants for the category types?
[19:54] <mfisch> mhall119: what do you mean?
[19:55] <mhall119> line 32 of the .c file:         scope_result.category = 0;
[19:55] <mfisch> mhall119: let me chekc the .h file
[19:56] <mfisch> mhall119: yeah I see some, let me try
[19:57] <olli_> hey Saviq, man you are still around...
[19:57] <mfisch> mhall119: okay, this worked for me, change the 0 to UNITY_CATEGORY_TYPE_NONE and see if that works for you
[19:57] <Saviq> olli_, yes, notifications landed, fixing the mock scopes to land
[19:57] <olli_> poor you, chance for me to bug you about scopes, notification and the universe
[19:58] <olli_> Saviq, ok
[19:58] <Saviq> olli_, it's the last remaining issue
[20:00] <mhall119> mfisch: yup, that works
[20:00] <mfisch> okay, I'll commit
[20:04] <mfisch> mhall119: he can we G+ for a few mins?
[20:05] <mhall119> sure
[20:06] <mhr3> mfisch, eek, no
[20:07] <mfisch> mhr3: context?
[20:07] <mhr3> mfisch, the category ids match index of the respective category in the CategorySet
[20:08] <mhr3> ideally Category would have an .id prop that would be set once you category_set_add() it, but it's not there
[20:08] <mhr3> mfisch, bottom line, define your own enum
[20:08] <mfisch> okay, so 0 is fine then
[20:09] <mhr3> or that, yes
[20:11] <mfisch> mhall119: okay, now re-pull it all and see if you have a Creation Date and Author line in the preview plz
[20:33] <mhall119> mfisch: looks good, I see the meta data
[20:33] <mfisch> Thanks mhall119
[20:36] <mhall119> mfisch: http://www.quickmeme.com/meme/3uwy5j/
[20:38] <dobey> where does Unity.Notifications come from in qml?
[20:39] <mhall119> dobey: where are you seeing it?
[20:49] <mhr3> dobey, that got merged a couple of hours ago
[20:49] <mhr3> you like bleeding edge, don't you? :)
[20:51] <dobey> mhall119: i'm trying to run lp:unity/8.0 and it's complaining about that now
[20:52] <dobey> mhr3: no, everything about this is a complete pain. :(
[21:00] <mhr3> dobey, you came to the game at very bad point
[21:04] <dobey> well it's not just the sudden breakage due to a new thing that is causing pain
[23:53] <Saviq> dobey, ppa:phablet-team/desktop-deps
[23:54] <Saviq> dobey, qtdeclarative5-unity-notifications-plugin
[23:54] <Saviq> dobey, sorry we didn't update the build scripts yet