[08:06] <pstolowski> sil2100: ping
[08:09] <sil2100> pstolowski: pong
[08:11] <pstolowski> sil2100: hi! do you know what's the status of landing the latest stuff in S?
[08:11] <sil2100> pstolowski: we're really close, Ted submitted the (probably) final fix for HUD
[08:11] <pstolowski> sil2100: awesome, so today is likely?
[08:13] <didrocks> pstolowski: what kind of fix can we expect for unity?
[08:14] <didrocks> (the scopes)
[08:14] <didrocks> btw :)
[08:14] <sil2100> pstolowski: I would say so yes
[08:14] <pstolowski> didrocks: no fix, just a small feature in libunity that's required for phablet tree
[08:14] <didrocks> ah ok
[08:15] <didrocks> pstolowski: are the slow previews being worked on?
[08:15] <didrocks> pstolowski: is it a server-side general issue?
[08:15] <didrocks> I see a lot of complains on *the* Internet :)
[08:15] <didrocks> (making even the default opening previews more frustrating)
[08:16] <sil2100> Yes, those slow previews make things really bad
[08:16] <sil2100> Since sometimes when I forget that you have to 'double-click' to open, the preview starts but loads really really long
[08:17] <sil2100> And it's made so bad that you can't really launch the app before the preview appears
[08:17] <davidcalle> sil2100, didrocks: previews are actually faster with right click. Since, on a left click there is a delay waiting for a double click.
[08:18] <pstolowski> sil2100, didrocks: the problem with apps is with a software-center helper service, that is started on demands for previews (to five us additional data); it goes away automatically, and it's startup is expensive
[08:18] <didrocks> davidcalle: hum, loading the images and loading the description takes up some seconds
[08:18] <pstolowski> s/five/give/
[08:19] <didrocks> pstolowski: ah, I think it's the main issue, is this daemon expensive?
[08:19] <didrocks> pstolowski: or when we get results from the app lens, should we start it already?
[08:19] <pstolowski> didrocks: yes, it easly eats up > 100MB of ram
[08:19] <pstolowski> didrocks: and it's python
[08:19] <didrocks> pstolowski: I think it's one of the main thing making the previews/100 scopes not as popular as it can be, do you know if anything is looked at for making the experience better?
[08:20] <pstolowski> didrocks: it's dbus-activated by 1st preview request, then it stays running for a few minutes
[08:20] <didrocks> (like starting it when hovering or whatever)
[08:21] <pstolowski> didrocks: yeah, I agree this sucks atm. and no, it's not actively being worked on now, but I'm sure we will get to it soon
[08:21] <davidcalle> didrocks, there used to be a fix for previews loading, where awhere preloaded.
[08:21] <davidcalle> didrocks, sorry, were preloaded*
[08:21] <didrocks> pstolowski: should I raise that to Thomas?
[08:21] <davidcalle> didrocks, ugh. a fix, from dednick, that preloaded previews.
[08:21] <sil2100> Pleaseee
[08:21] <didrocks> davidcalle: hum, I think it's really the apps scope case which is the worst, not really the others
[08:22] <pstolowski> didrocks: I'd say just open a bug and make it high/crit for now
[08:22] <didrocks> but eating too much memory?
[08:22] <didrocks> ok
[08:22] <sil2100> Wellark, didrocks: HUD TESTS PASSED \o/
[08:22] <sil2100> Woohoo!
[08:22] <didrocks> sil2100: \o/\o/\o/
[08:22] <pstolowski> didrocks: and set it to affect SC
[08:23] <sil2100> Once armhf gets published, I'll try publishing the stack
[08:23] <didrocks> pstolowski: I'll do on both, apps scopes and SC
[08:23] <didrocks> sil2100: sweet :)
[08:24] <Saviq> MacSlow, how are we re: notifications, can we land today? :)
[08:24] <sil2100> didrocks: libdbusmenu still building for armhf, but once that's done, I'll re-run indicators as well - then, unity should run as well, so we might have a green Head today even! Shock
[08:25] <MacSlow> Saviq, could not get the 3 tests going... also was held up by vala-related compilation errors under Saucy (but at least those I got sorted)
[08:25] <didrocks> sil2100: you can rerun indicators already
[08:25] <didrocks> sil2100: it will wait on it and run the tests
[08:25] <didrocks> sil2100: zomg a green Head \o/
[08:26] <Saviq> MacSlow, can we help on the tests?
[08:26] <MacSlow> Saviq, and I can no longer see any notifications (with current Saucy) if I run the shell on my desktop...
[08:26] <Wellark> sil2100: :)
[08:27] <Saviq> MacSlow, :/, let me know if you need help
[08:27] <MacSlow> Saviq, first I need to see what/if notifications are also broken on the device itself...
[08:27] <MacSlow> Saviq, sure
[08:28] <MacSlow> Saviq, the recent state of saucy made things worse for me atm
[08:29] <pstolowski> didrocks: thanks
[08:33] <didrocks> pstolowski: please, do not hesitate to edit the description (bug #1192081)
[08:45] <sil2100> didrocks: hmm, did you re-enable -proposed for daily-release?
[08:46] <sil2100> didrocks: since indicators check failed because of "indicator-datetime : Depends: libical1 (>= 1.0) but it is not installable"
[08:47] <didrocks> sil2100: I did so, let me look
[08:47] <didrocks> sil2100: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+edit-dependencies
[08:47] <didrocks> sil2100: maybe there is a trickery if the upload was done before the switch changed?
[08:49] <sil2100> Just to make sure - if a PPA has a dependency on -proposed, when the PPA is added to a system and packages fetched from that PPA, will the system also fetch the deps from -proposed then?
[08:50] <sil2100> Or do we have to enable -proposed explicitly on that machine as well?
[08:50] <sil2100> didrocks: ^
[08:51] <didrocks> sil2100: people has to fetch it explicitly as well, the deps are only for build-deps AFAIK
[08:51]  * tsdgeos finds out why the lvwph test failed in CI
[08:52] <tsdgeos> obviously there was a bug in the code :-/
[08:52] <sil2100> didrocks: ok, so hm, we need to add the -proposed dep to the daily-release otto machine then? hmm
[08:52] <sil2100> didrocks: since otherwise it won't find the libical dep
[08:55] <nic-doffay> Saviq, feeling better today?
[08:55] <Saviq> nic-doffay, yeah, thanks
[08:55] <nic-doffay> Saviq, good to hear!
[08:55] <nic-doffay> Saviq, can you recommend me anything from the blueprint to work on?
[08:56] <didrocks> sil2100: ah, only the -check failed
[08:56] <didrocks> not -build
[08:56] <nic-doffay> Or something else...
[08:56] <didrocks> sil2100: yeah, fair point, mind pinging jibel? On other discussions :)
[08:59] <sil2100> didrocks: ok!
[08:59] <sil2100> jibel: ping!
[09:00] <jibel> sil2100, pong
[09:01] <sil2100> jibel: hello! So, we have a problem in the indicator's check job using otto - we would probably need -proposed enabled in that test machine
[09:01] <sil2100> jibel, didrocks: you guys think that would be ok?
[09:02] <sil2100> Basically indicator-datetime is built in our PPA, but probably it won't migrate from -proposed to the universe if we don't make a release
[09:02] <didrocks> I think it's needed for handling the transitions
[09:09] <jibel> sil2100, to enable proposed you can add a file that contains the repository in the directory packages/ of the testsuite
[09:10] <jibel> sil2100, for example create a file packages/proposed.repo that container the line: deb "http://archive.ubuntu.com/ubuntu/ saucy-proposed main universe restricted multiverse"
[09:10] <jibel> s/container/contains
[09:10] <jibel> (without quotes even)
[09:12] <sil2100> o/
[09:12] <sil2100> jibel: trying that
[09:14] <jibel> hm, actually there is a single testsuite for raring and saucy that'll be a problem if we specify a release :/
[09:17] <sil2100> Maybe we could somehow control this from jenkins?
[09:24] <jibel> sil2100, I suppose you need that now or can that wait end of afternoon? I'll have more time to fix this detail.
[09:25]  * greyback moving to office, back in 30
[09:25] <sil2100> jibel: it would be best if we had that fixed as soon as possible, as many people are waiting for the releases
[09:26] <jibel> didrocks, is there any test planned for raring in the coming hours?
[09:26] <seb128> sil2100, can't we just do a direct archive upload of indicator-datetime to finish the libical transition?
[09:26] <seb128> then merge the changelog in trunk
[09:26] <didrocks> sil2100: do you need anything on raring or can we let jibel's playing? ^
[09:26] <seb128> and daily release
[09:27] <didrocks> seb128: we'll have the same issue tomorrow, as long as libical didn't migrate
[09:28] <seb128> didrocks, well, my understanding was that indicator-datetime was the only thing blocking it
[09:28] <seb128> didrocks, so it will move to release if somebody does a manual upload
[09:28] <jibel> didrocks, if not I'll enable proposed temporarily then disable it until I've time to land a fix to support per release deb entries later today
[09:28] <didrocks> seb128: weird? IIRC, riddel uploaded it though
[09:28] <didrocks> jibel: yeah, let's do that
[09:28] <seb128> https://launchpad.net/ubuntu/+source/indicator-datetime/12.10.3daily13.06.07-0ubuntu2
[09:28] <seb128> didrocks, ftbfs
[09:29] <seb128> didrocks, the pthread issue is fixed in trunk
[09:29] <didrocks> seb128: ahah, the same thing :)
[09:29] <didrocks> seb128: well, let's hack it now that we are close to release
[09:29] <seb128> if somebody upload trunks manually you should unblock libical
[09:29] <didrocks> jibel: please go ahead ^
[09:29] <seb128> didrocks, thanks ;-)
[09:29] <didrocks> yw :)
[09:30] <Cimi> mzanetti, got a chance?
[09:32] <sil2100> didrocks: raring can wait ;)
[09:33] <sil2100> jibel: I'm leaving it in your hands! Give me a sign once it's all ok ;)
[09:34] <jibel> sil2100, done
[09:34] <jibel> sil2100, give it a try
[09:35] <jibel> sil2100, also I pushed a new feature that I wanted to release after today's runs to capture memusage, if any job fails let me know.
[09:39] <Cimi> Saviq, well, I can move to something else while I wait reviews if you're ok
[09:40] <Saviq> Cimi, jump over to the shell to make it theme-able
[09:40] <sil2100> jibel: thanks!
[09:40] <Cimi> Saviq, chat?
[09:40] <Saviq> Cimi, aren't we? :)
[09:40] <Saviq> Cimi, mumble?
[09:40] <Cimi> Saviq, :P
[09:41] <sil2100> jibel: will the raring checks work now as well? Or currently only saucy?
[09:43] <jibel> sil2100, only saucy
[09:44] <jibel> sil2100, there is no transition in raring that'd require -proposed I hope ? :)
[09:49] <sil2100> jibel: nooo ;)
[09:49] <sil2100> jibel: thanks!
[09:53] <mzanetti> Cimi: sorry, no... I started a bit but didn't come too far as it was quite late already.
[10:12] <mzanetti> Cimi: how would you like the review?
[10:12] <mzanetti> Cimi: pastebin like last time? or everything via mail?
[10:12] <Cimi> mzanetti, mail
[10:12] <mzanetti> Cimi: ack
[10:13] <Cimi> mzanetti, no rush, I'm looking at unity theming, then I leave for the afternoon and be back tonight
[10:35] <sil2100> bregma: hi
[10:37] <sil2100> bregma, dednick, pstolowski: I still see a lot of failures in unity... some of them might disappear if we use the new hud and bamf, but hm
[10:39] <pstolowski> sil2100: url?
[10:40] <mzanetti> Cimi: done
[10:41] <mzanetti> should keep you busy for a bit :D
[10:41] <sil2100> pstolowski: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/151/testReport/
[10:42] <mzanetti> Cimi: in the pasted code snippets, search for "REVIEW"
[10:42] <Cimi> mzanetti, which one?
[10:43] <mzanetti> Cimi: I've sent a mail with a combination of links and text
[10:43] <Cimi> mzanetti, oh sorry, I always forget to keep tb running
[10:43] <Cimi> :)
[10:48] <Cimi> mzanetti, had a quick look
[10:48] <Cimi> let's have a chat later when I'll be back
[10:48] <Cimi> I'm going to take those photos, not sure how long does it take but I bet I'll be back before the end of the working day
[10:49] <mzanetti> Cimi: ok
[11:03] <mhr3> sil2100, how does one get to the autopilot videos these days?
[11:04] <didrocks> mhr3: it should be fairly logical now :)
[11:04] <didrocks> mhr3: let's see if it is, let's say you want to see them on the intel run:
[11:04] <didrocks> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/151/label=autopilot-intel/
[11:04] <didrocks> tell me if you find them in the artefacts and what's your thoughts
[11:05] <mhr3> didrocks, yea, i was on http://10.97.0.1:8080/job/autopilot-saucy-daily_release/151/label=autopilot-intel/testReport/? and didn't see the build artifacts link anywhere
[11:06] <sil2100> mhr3: you need to click on the given machine to see those
[11:06] <didrocks> mhr3: well, that's a jenkins thing, it's never on the testReport/ page
[11:06] <sil2100> mhr3: so you need to go back, go to the given machine and then you see the artifacts
[11:06] <mhr3> yea, yea, found it now, thx
[11:32] <pstolowski> sil2100, didrocks, mhr3: there is something odd about those test failures - videos are very short, there is no waiting etc. for results (which normally indicates results didn't show up on time) - instead they fail on AttributeError: 'NoneType' object has no attribute 'get_results'. If you look at e.g. unity.tests.test_shopping_lens.ShoppingScopeTests.test_application_scope_has_shopping_results, there are shopping results on the video
[11:32] <mhr3> pstolowski, i'm fixing that right now
[11:32] <didrocks> mhr3: you did find one root cause?
[11:32] <mhr3> yes
[11:33] <sil2100> \o/
[11:34] <didrocks> wooow :)
[11:36] <Saviq> dednick, hey, can you please look at https://bugs.launchpad.net/ubuntu-touch-preview/+bugs?field.tag=saucy-regression
[11:42] <mhr3> didrocks,
[11:42] <mhr3> https://code.launchpad.net/~mhr3/unity/capital-s/+merge/170045
[11:43] <mhr3> https://code.launchpad.net/~mhr3/unity-scope-home/capital-s/+merge/170046
[11:43] <mhr3> https://code.launchpad.net/~mhr3/unity-lens-music/capital-s/+merge/170047
[11:43] <mhr3> https://code.launchpad.net/~mhr3/unity-lens-video/capital-s/+merge/170048
[11:44] <mhr3> being consistent involves a couple of branches :)
[11:46] <sil2100> mhr3: thanks!
[11:46] <sil2100> Let's get those reviewed
[11:46] <sil2100> pstolowski: ^ could you?
[11:46] <mhr3> sil2100, i think you can handle ;)
[11:47] <nic-doffay> pete-woods, pushed your comments to that branch.
[11:47] <sil2100> pstolowski, mhr3: btw. would it be possible for your team to assign one person that would look at the daily test results for unity every morning, making sure that nothing super-duper got broken?
[11:47] <pete-woods> nic-doffay: cool, thanks!
[11:47] <sil2100> If, of course, there would be a test result ;p
[11:48] <mhr3> sil2100, do we really need to poll instead of listening for events (you pinging us)? :)
[11:49] <sil2100> mhr3: well, theoretically the tests failing is a job for upstream, so you guys ;p We're only here to take care of releasing and maintainance of the tools
[11:50] <sil2100> mhr3: we're around to fix some other things like something packaging wise got broken or the tools failed and no tests got returned
[11:50] <mhr3> sil2100, yes, but this polling would span 5 teams, that's a lot of wasted time if one person from each team looks at the results only to find out that it's not their fault
[11:53] <sil2100> mhr3: well, I don't mind doing that, but anyway upstream is maintaining their own trunks, so just having one person open up a link for a check job every morning to see if something got broken recently in unity trunk wouldn't be such a bad thing, since this might speed things up
[11:54] <dednick> Saviq: sure
[11:54] <sil2100> mhr3: as for instance I have a lot of stacks to check right now, so for instance when I finally have a time to see that there are a lot of unity failures going on, you guys could have noticed that already much faster and it might have been fixed already
[11:54] <mhr3> sil2100, on the other hand it slows down other upstream tasks :)
[11:54] <sil2100> mhr3: true true ;)
[11:54] <sil2100> mhr3: just a something to consider
[11:59] <sil2100> I wonder why CI failed for https://code.launchpad.net/~mhr3/unity-lens-video/capital-s/+merge/170048
[12:12] <mhr3> sil2100, let's fix that with next mp :)
[12:15] <mhr3> sil2100, ok, so this one fixes it - https://code.launchpad.net/~mhr3/unity-scope-home/revert-120/+merge/170060
[12:16] <mhr3> didrocks, this was actually good test for the CI stuff, what does it do when it's in progress of merging a branch and that gets un-approved?
[12:17] <sil2100> mhr3: if the branch got picked up by the merger before we managed to reject it, it will merge it in anyway
[12:17] <sil2100> IIRC
[12:18] <sil2100> But the merger does one thing at a time, so in some moment's we'll be sure if anyting landed or not
[12:19] <mhr3> so let's hope we were fast enough...
[12:19] <mhr3> or rather ci slow enough :)
[12:20] <sil2100> didrocks: hm, when re-running with "CHECK_WITH_WHOLE_PPA", should I rebuild everything or use 'foo'?
[12:20] <sil2100> didrocks: for instance for the case of indicators
[12:26] <sil2100> Trevinho: ping!
[12:38] <sil2100> mhr3: so just a fix to the home lens is needed?
[12:38] <sil2100> s/lens/scope
[12:45] <sil2100> fginther: ping!
[12:57] <didrocks> mhr3: I don't do, I didn't write the version 2. From what I experienced though, it's failing to merge :)
[12:57] <didrocks> sil2100: depends, do you need to rebuild them?
[12:57] <didrocks> sil2100: CHECK_WITH_WHOLE_PPA ignores rebuilding anything
[12:58] <Trevinho> sil2100: pong
[13:01] <mhr3> sil2100, right
[13:02] <dandrader> mzanetti, would you have time to review this one? https://code.launchpad.net/~dandrader/unity/8_tryTest/+merge/169527
[13:02] <fginther> sil2100, ping
[13:03] <mzanetti> dandrader: not right now. how urgent is it?
[13:03] <dandrader> mzanetti, not urgent. np
[13:03] <dandrader> tsdgeos, would you have time to review this one? https://code.launchpad.net/~dandrader/unity/8_tryTest/+merge/169527
[13:03] <tsdgeos> ah i saw it this morning
[13:04] <mzanetti> dandrader: if you can wait, I can do it tonight or tomorrow
[13:04] <mzanetti> unless tsdgeos wants to have it :)
[13:04] <dandrader> mzanetti, exactly :)
[13:04] <sil2100> didrocks: hm, not sure if a rebuild is needed, since indicator-datetime anyway depends on libical, so I would just want it to be fetched
[13:05] <tsdgeos> what's the "thing" in there? is there no change we can get that into upstream qmlscene?
[13:05] <sil2100> didrocks: but I tried re-running just with 'foo' and it failed fetching 'libical'
[13:05] <tsdgeos> s/change/chance
[13:05] <sil2100> didrocks: i.e. extra packages installed it said
[13:05] <dandrader> tsdgeos, It's using the MouseTouchAdaptor
[13:05] <sil2100> Trevinho: hi!
[13:05] <tsdgeos> ah, that's ours
[13:06] <mzanetti> dandrader: +1 on the make tryFoo
[13:06] <didrocks> sil2100: even with CHECK_WITH_WHOLE ppa?
[13:06] <sil2100> Trevinho: so, I see a commit in lp:bamf/0.4 (for raring) that was fixing some Makefiles for jenkins
[13:06] <mzanetti> awesome stuff, dandrader
[13:06] <Trevinho> sil2100: yes
[13:07] <dandrader> mzanetti, thanks!
[13:07] <Trevinho> sil2100: ci and builder weren't working otherwise
[13:07] <tsdgeos> dandrader: would it be possible to split a bit more our changes (i.e. the use of MouseTouchAdaptor) and the "copied" qmlscene.cpp code (if there is any, i understand there is) so it's easier to "sync" in the future?
[13:07] <sil2100> didrocks: yes, I checked that, and from what I see it's still failing in the same way
[13:07] <sil2100> Trevinho: so that's necessary for everything to work, yes?
[13:07] <didrocks> sil2100: oh interesting, let me have a look in a few with jibel
[13:07] <sil2100> didrocks: thanks!
[13:07] <didrocks> yw :)
[13:07] <Trevinho> sil2100: yep...
[13:08] <sil2100> Trevinho: ok, hm, is there a bug for this by any chance?
[13:08] <dandrader> tsdgeos, you mean first bring in qmlscene and in a separate commit modify it to use MouseTouchAdaptor?
[13:08] <sil2100> is/was
[13:08] <dandrader> tsdgeos, although still in the same merge proposal?
[13:08] <Trevinho> sil2100: I didn't open, as I noriced when pushing something else, but i can add it if you want
[13:09] <tsdgeos> dandrader: no, i mean seperate files (that'd be awesomse so one could copy the new qt file) and/or more isolated places on the code, but i guess that's not really easy/possible since the main.cpp is even embedded there
[13:10] <tedg> sil2100, So it looks like HUD is good, no?
[13:10] <sil2100> tedg: yes, thanks! Awesome \o/
[13:10] <tedg> Woot!  /me does a happy dance
[13:11] <sil2100> tedg: we'll release everything today hopefully!
[13:11] <tedg> sil2100, That'd be great, thanks for all the debug logs!
[13:12] <sil2100> hehe, thanks for the fixes ;) Finally this bug got squished
[13:17] <dandrader> tsdgeos, hmmm, I'm having a hard time imagining how I could move our changes to a separate file... Anyway the diff is a couple of lines only. Quite minimal
[13:18] <sil2100> Trevinho: could you create a bug for that build-system issue?
[13:18] <sil2100> Trevinho: I think the SRU team would be much more happy with that then ;)
[13:19] <sil2100> Trevinho: I will modify the changelog to include that one, since I'm cleaning up things anyway
[13:19] <fginther> sil2100, pong?
[13:20] <sil2100> fginther: hello :) Sorry, missed your pong, too many blinking places
[13:20] <sil2100> fginther: but my issue already got resolved
[13:20] <fginther> sil2100, no problem
[13:24] <Trevinho> sil2100: fine, thanks for the head up
[13:31] <Saviq> nic-doffay, dednick, greyback standup
[13:31] <Saviq> Cimi, ^
[13:31] <greyback> coming, mumble stuck
[13:31] <Saviq> dandrader, ^
[13:31] <Saviq> k
[13:46] <mterry> didrocks, cyphermox: indicators stack has been failing for a while; I've got an interest in having libusermetrics land in saucy.  Do you think it's easier to fix the stack or manually upload the package to saucy first just to get it going through NEW, etc?
[13:47] <didrocks> mterry: we are quite close to get everything finally fixed
[13:47] <didrocks> so better to wait :)
[13:47] <kgunn> nic-doffay: infog looks kick-a on the device! i just updated to saucy ...and bam it was there
[13:47] <sil2100> didrocks: any luck with the indicator stack re-running with the whole PPA ;) ?
[13:48] <nic-doffay> kgunn, yeah. The colours will change again though, otherwise it's staying like that.
[13:48] <mterry> didrocks, ok
[13:48] <didrocks> sil2100: fix is deploying right now
[13:48] <sil2100> Awesome
[13:49] <didrocks> sil2100: done, you can relaunch it :)
[13:50] <sil2100> Foo with whole, yes?
[13:52] <cyphermox> fix the stack
[13:52] <cyphermox> I'll go look at what's up with libusermetrics again
[13:53] <cyphermox> mmkay I guess libical1 was added already
[13:55] <cyphermox> perhaps not
[14:00] <dobey> http://pastebin.ubuntu.com/5774919/ <- anyone know why this would happen in lp:unity/phablet?
[14:05] <devgru> hello everyone
[14:17] <greyback> Saviq: can I get your input on this API proposal: http://studio.sketchpad.cc/EEd2PSjTRn . HUD needs this API to maintain its own application stack internally.
[14:18] <Saviq> greyback, about that - doesn't HUD only need a single app and not the whole stack?
[14:19] <greyback> Saviq: I recall asking tedg that, he maintained they needed the whole stack. tedg, can you confirm please?
[14:20] <tedg> Saviq, We use it to grab the menus in advance and pre-load.  It's an optimization, but one I'd like to keep.
[14:21] <tedg> Saviq, Not as much an issue on the smaller apps like the phone, but on things like the GIMP it can help quite a bit.
[14:21] <Saviq> tedg, mhm, got it
[14:26] <Saviq> greyback, it feels like "Window(Un)Focused" is overkill, could we have "FocusedWindowChanged" with null for "going to dash"?
[14:27] <greyback> Saviq: no objection here
[14:31] <Saviq> greyback, app_uri is the app id?
[14:31] <greyback> Saviq: yes
[14:34] <Saviq> greyback, looks sane, did you talk with Robert about this? at least in Mir the term seems to be Surface and not Window, not sure if that should be used here, too
[14:34] <mhr3> dobey, people here know stuff ;)
[14:35] <Saviq> greyback, or Session, even (do we want menus per-surface/window or per-app?) tedg?
[14:36] <tedg> Saviq, Yes :-)
[14:36] <tedg> Saviq, We'll need that for the desktop cases.
[14:36] <greyback> Saviq: do we want to use their terminology though? Those are very display server terms
[14:36] <tedg> Saviq, For the phone cases they should be 1:1, but when we have to handle things with real window management, we'll need more.
[14:37] <dobey> mhr3: i asked in here, and nobody replied :(
[14:42] <dobey> am i supposed to use lp:unity/phablet or lp:unity/8.0?
[14:44] <Saviq> dobey, lp:unity/8.0
[15:06] <tsdgeos_> dandrader: so still want me to do https://code.launchpad.net/~dandrader/unity/8_tryTest/+merge/169527 or someone is doing it?
[15:14] <dandrader> Saviq, https://code.launchpad.net/~dandrader/unity/phablet_developmentHasMoved/+merge/170109
[15:14] <dandrader> tsdgeos_, please do review it
[15:15] <dandrader> tsdgeos_, don't forget to claim it to have it clear that you got it covered
[15:18] <mhr3> Saviq, do we have any plan for abi breaks in unity-core? it's very much not doable to keep abi compatibility with a c++ lib... :/
[15:19] <dandrader> Saviq, btw, auto-landing will never approve it. can I just push it?
[15:21] <sil2100> Trevinho: any luck with opening that bug ;) ?
[15:21] <Trevinho> sil2100: oh, sorry... :)
[15:24] <tsdgeos_> dandrader: can't claim it, no button for that, maybe greyback did claim it?
[15:24] <sil2100> Trevinho: just a quick bug would be ok, we'll SRU it later ;)
[15:25] <Trevinho> sil2100: bug #1192216
[15:25] <greyback> tsdgeos_: I didn't claim, just made a comment
[15:25] <sil2100> Trevinho: thanks! Adding to changelog
[15:26] <dandrader> tsdgeos_, I'll just add you as a reviewer then
[15:27] <dobey> bah, lp:unity/8.0 is crashing with the exact same stack trace as lp:unity/phablet was, for me :(
[15:30] <dobey> inside the moc-genrated plugin code :(
[15:35] <Saviq> dandrader, right, yea
[16:07] <olli_> Saviq, ping
[16:07] <Saviq> olli_, pong
[16:07] <Saviq> olli, sorry for not being there yesterday, something slapped me down flat
[16:07] <olli> Saviq, any word on the scopes?
[16:08] <Saviq> olli, we need to land notifications in sync with them, so that we can get rid of the phablet version of nux
[16:08] <Saviq> olli, the scopes support itself is ready
[16:08] <Saviq> olli, we're polishing up notifications
[16:10] <Saviq> olli, but I don't want to push it today, want to have a bit more time tomorrow morning to get everything into shape and land
[16:10] <olli> ok
[16:10] <olli> thx for the update saviq
[16:35] <mhall119> mfisch: ping
[16:35] <mfisch> mhall119: pong
[16:36] <mhall119> mfisch: I want to test your scopes tutorial code
[16:36] <mhall119> gimme!
[16:46] <mfisch> mhall119: ha, once it works a bit better, sure
[16:52] <mhall119> mfisch: of course, keep me in the loop and I'll jump on it as soon as it's ready
[16:52] <mfisch> mhall119: ok, it's been slow going
[16:53] <mhall119> of course it has, it's C :)
[17:09] <mfisch> it was far easier in singlet
[17:11] <mfisch> mhall119: do you have calle's scope already?
[17:13] <mhall119> I have lots of his scopes, I'm on Saucy :)
[17:13] <mhall119> did you have one in particular?
[17:13] <mfisch> his example scope for openclipart
[17:14] <mhall119> http://bazaar.launchpad.net/~dpm/+junk/openclipart/files ?
[17:14] <mfisch> no thats the C code
[17:15] <mfisch> this is the link I have
[17:18] <mhall119> mfisch: we should port Singlet to C :)
[17:18] <mhall119> call is Cinglet
[17:18] <mhall119> then laugh maniacally when people try to say it out loud
[17:32] <mfisch> mhall119: can you tell me how to stop Unity from changing my filters when the search completes?
[17:37] <mhall119> mfisch: disable the smart scope service
[17:38] <mhall119> the smart scope service is what tells your dash what scopes to try
[17:56] <mfisch> gah how do you open a URL in a browswer from C
[17:56]  * mfisch checks glib
[18:04] <dednick> Saviq: ping
[18:06] <dednick> Saviq: i've moved the indicator-client and indicator files to a src folder off the root path. If that's alright, I think we should probably also move the other random cpp code in there as well (main, paths, MouseTouchAdapter, etc).
[18:06] <mfisch> mhall119: lp:~mfisch/+junk/openclipart, I'm still fixing things though
[18:06] <mfisch> mhall119: but it's semi-usable
[18:11] <Saviq> dednick, we should probably have a "data" top-level folder for the .indicator files, the .desktop file and such
[18:12] <Saviq> dednick, and +1 on src
[18:18] <mfisch> wow
[18:18] <mfisch> that chnag just took down unity
[18:31] <mhall119> thanks mfisch, I'll take a look
[18:32] <mfisch> mhall119: I have the preview image working, I need to make more fixes and i will push in a bit
[18:36] <mhall119> mfisch: david had a small GUI app that you could use to test scopes and see what they returned, do you know if that will work with these new C scoped?
[18:36] <mfisch> not sure, sorry
[18:36] <mhall119> didn't figure you would, but it was worth asking
[18:37] <mfisch> I was told about libunity-tool for testing, perhaps that's it?
[18:37] <mfisch> I just install the scope and service and run the scope by hand
[18:37] <mhall119> might have been, I don't remember the name now
[18:39] <mhall119> that scope doesn't look so bad
[18:39] <mhall119> I mean, it's still C, but all things considered, not bad
[18:46] <mfisch> mhall119: haha
[18:46] <mfisch> mhall119: update it, the open URL and preview icon work
[18:46] <mfisch> mhall119: for opening the icon, i'm doing a system to xdg-open, not pretty
[18:46] <mfisch> but functional
[18:47] <mfisch> maybe i'll add a download button
[18:48] <mhall119> mfisch: you should just be able to tell Unity to open the URI
[18:48] <mhall119> instead of calling xdg-open yourself
[18:48] <mhall119> that's how it used to be anyway
[18:48] <mfisch> there's a handle type called GOTO_DASH_URI which I thought would work
[18:48] <mfisch> but did not
[18:49] <mhall119> I think NOT_HANDLED tells unity "I didn't handle this, so you have to"
[18:49] <mfisch> let me try that
[18:49] <mfisch> when I did this for the stock ticker, I did HIDE_DASH
[18:50] <mfisch> mhall119: what about having a "Save" button and calling wget?
[18:50] <mfisch> that might be fun
[18:52] <mhall119> IIRC, HIDE_DASH means "I'm doing something with this, you can close the dash now"
[18:52] <mhall119> SHOW_DASH means "I'm doing some stuff, but want the Dash to remain open"
[18:52] <mhall119> not sure about GOTO_DASH_URI
[18:52] <mfisch> well I'll be
[18:52] <mfisch> it worked
[18:52] <mfisch> thanks mhall119
[18:53] <mhall119> :)
[18:53]  * mhall119 puts on his lead developer cape
[18:53] <mfisch> think download or save might be a nice button?
[18:53] <mhall119> no, that kind of defeats the purpose of the dash being "you don't care where it is"
[18:54] <mhall119> but if you can copy the image itself into the clipboard....that would be interesting
[18:54] <mfisch> I guess if I wanted to downlaod it, I can go through the browser
[18:54] <mhall119> yeah
[18:54] <mfisch> oh, thats probably 10k lines of C code or so ;)
[18:54] <mhall119> probably :)
[18:54] <mhall119> for the boiler plate anyway
[18:54] <mhall119> the actual functionality might be more
[18:55] <mfisch> I think instead I'll clean up the code more so Sr planella can make a doc on it
[18:58] <mhall119> probably the right idea, yeah
[18:59] <mfisch> mhall119: are you a qmake expert/
[18:59] <mfisch> mhall119: I want to change the default CFLAGS
[19:01] <mfisch> lead developer google gave me some ideas
[19:07] <mfisch> mhall119: more updates, mainly compiler warning fixes, but also I dropped the system() call
[19:27] <mfisch> mhall119: do we want this packaged?
[19:32] <mfisch> may as well I dont have much else to do
[19:32] <mfisch> actually it may be simpler without package cruft
[19:33] <mhall119> yeah, let's leave it without for now
[19:33] <mhall119> since it's going to be a tutorial on how to write scopes, not package them
[20:02] <mhall119> mfisch: what package do I need to get mrss.h includes?
[20:04]  * mhall119 tries libmrss0-dev
[20:05] <mhall119> ok, that worked
[20:05] <mhall119> mfisch: but now I get:
[20:05] <mhall119> gcc: error: unrecognized command line option ‘-Wnounused-variable’
[20:28] <dobey> anyone know why search doesn't work in lp:unity/8.0 on the dash home lens?
[20:52] <mhr3> dobey, cause it's disabled
[20:53] <dobey> how can i enable it?
[20:54] <mhr3> that is a good question
[20:54] <mhr3> i'd guess that it'll start working when all the pending branches land
[21:05] <dobey> is that happening tonight? :)
[21:18] <mhr3> we wish
[21:19] <mhr3> but our wishes were not answered for the past couple of days
[21:23] <dobey> :-/
[21:24] <tedg> dobey, mhr3 forgot to leave sacrificial cookies on the alter of Santa.
[21:25] <mhr3> tedg, and on yours! :P hud test failures caused some delays too
[21:26]  * tedg eats all the cookies!  NOM NOM NOM!
[21:26] <mhr3> i'm starting to think that any plan should include extra 2 weeks of integration
[22:08] <mhall119> mfisch: hey man, I still can't get your scope code to compile, ping me when you're around