[01:51] <smspillaz> Walther: it is, you just need to enable it
[01:51] <smspillaz> Walther: see the grid plugin options in ccsm
[01:52] <smspillaz> quarter-split is not really as robust though, as we can't use the same constraints mechanism that we get with semimax windows
[07:11] <mzanetti> good morning
[07:40] <tsdgeos> mzanetti: welcome
[07:40] <mzanetti> tsdgeos: hi
[07:40] <mzanetti> thanks
[07:41] <Saviq> mzanetti, welcome back
[07:41] <mzanetti> cheers Saviq
[07:42] <mzanetti> anything for me to catch up?
[07:43] <Saviq> mzanetti, business as usual I think
[07:43] <mzanetti> Saviq: ok.... going through my mails and then continue with jenkins
[07:44] <Saviq> mzanetti, yeah, I'd like to do a review of coverage with you - early next week?
[07:44] <mzanetti> Saviq: ok
[08:00] <om26er> Trevinho, Hi!
[09:20] <seb128> hey unity hackers
[09:20] <seb128> seems like the fix for https://bugs.launchpad.net/unity/+bug/1108956 broke some unity tests
[09:21] <seb128> if you do e.g "super-m" "super", it used to open the music lens and then close the dash
[09:21] <seb128> now it does come back to the home lens on "super"
[09:21] <seb128> that breaks tests like
[09:21] <seb128> http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-ati/16/testReport/unity.tests.test_dash/DashRevealTests/test_command_lens_shortcut/
[09:21] <seb128> "The test left the dash open"
[09:21] <davidcalle> didrocks, https://code.launchpad.net/~davidc3/cupstream2distro-config/remove-scopes-target-branches/+merge/157304
[09:22] <didrocks> davidcalle: thanks! I'm modifying unity-scope-home as well
[09:22] <didrocks> and commiting this
[09:22] <seb128> sil2100, hey
[09:22] <seb128> sil2100, ^ see, I just did some investigation on failing tests
[09:23] <didrocks> davidcalle: pushed, thanks
[09:23] <davidcalle> didrocks, ty!
[09:25] <didrocks> fginther: once you are around, can you please deploy rev 149 from cupstream2distro-config?
[09:25]  * didrocks does the daily-release deployement
[09:25] <davidcalle> didrocks, soon , we will have https://code.launchpad.net/unity-scope-ubuntuone too :) But it's still WIP
[09:25] <didrocks> davidcalle: I heard about it! great :)
[09:33] <nic-doffay> Still up for review everyone: https://code.launchpad.net/~nicolas-doffay/unity/page-header-test/+merge/155242
[09:51] <seb128> sil2100, https://bugs.launchpad.net/unity/+bug/1164915
[09:58] <Saviq> nic-doffay, so, you want to fix PageHeader.qml to not reference "greeter" directly
[09:59] <nic-doffay> That's right.
[09:59] <Saviq> nic-doffay, and then you want to provide a greeter-like object in the test that will have the "shown" property - and test whether changing that value affects the PageHeader accordingly
[09:59] <nic-doffay> Correct.
[10:11] <nic-doffay> Saviq, regarding the controls test, after looking taking a look at tst_Stage, would something similar to the following be suitable (taken from tst_Stage)? https://pastebin.canonical.com/88500/
[10:14] <sil2100> seb128: hi! Looking at those, sorry I didn't answer earlier, I fell asleep by accident ;)
[10:15] <seb128> sil2100, hey, I filed https://code.launchpad.net/~seb128/unity/1164915-fix/+merge/157313 with a revert and didrocks acked it
[10:15] <nic-doffay> Sorry about that Saviq, back.
[10:15] <seb128> sil2100, sleeping is what night are for :p
[10:17] <sil2100> seb128: I know ;) Not feeling too well today though - indeed I see this regression here, strange that we didn't notice it earlier
[10:17] <Saviq> nic-doffay, well, yeah, but needs to be adapted to the case at hand, so you would have at least a button to trigger the search entry
[10:17] <seb128> sil2100, oh, get some rest if you are not feeling well
[10:17] <Saviq> nic-doffay, and a checkbox that mimics greeter.shown
[10:17] <Saviq> nic-doffay, and another checkbox to change the width
[10:18] <seb128> sil2100, in any case revert is on its way and we will retry tests to see what's the status, so no hurry for other changes
[10:19] <nic-doffay> What purpose does the AppControl serve Saviq ? I was mainly wondering about that. Is it specific to the Stage test?
[10:20] <sil2100> seb128: the ps-unity-autopilot-release-testing job?
[10:21] <sil2100> seb128: ah, the -generic- job I see
[10:21] <seb128> sil2100, right, http://10.97.0.1:8080/view/cu2d/view/Raring/view/Unity/job/cu2d-unity-raring/
[10:24] <sil2100> But this is really strange, since rev 3266 was around for quite a while IIRC, and we didn't notice this regression during unity-release-* jobs
[10:29] <Saviq> nic-doffay, yes
[10:29] <Saviq> nic-doffay, you won't need that
[10:30] <seb128> sil2100, did you have a successful run since?
[10:30] <Saviq> nic-doffay, you'll be fine with just standard buttons and checkboxes
[10:31] <seb128> sil2100, the commit landed on the 2nd and the run on the 3rd was http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/6/
[10:31] <seb128> sil2100, 157 fails
[10:31] <sil2100> seb128: now I see that the possible test run didn't really happen even
[10:32] <sil2100> seb128: so indeed it's the faulty commit
[10:32] <sil2100> Since the commit has been made after the test run
[10:33] <nic-doffay> Would you advise using this code from tst_Stage Saviq ? https://pastebin.canonical.com/88502/
[10:37] <nic-doffay> I'm mainly concerned about where to place all these test buttons.
[10:39] <mzanetti> hey nic-doffay! How is it going?
[10:39] <nic-doffay> Good!
[10:39] <nic-doffay> How are you?
[10:39] <mzanetti> nic-doffay: the PageHeader tests good now?
[10:39] <mzanetti> nic-doffay: yeah, I'm great!
[10:39] <mzanetti> thanks
[10:39] <nic-doffay> Almost there mzanetti just have to add some control tests. Feel free to give an opinion!
[10:40] <mzanetti> nic-doffay: ok, I'll check it out
[10:40] <nic-doffay> Mainly interested in placement in the test.
[10:40] <nic-doffay> I'm assuming the control test components shouldn't be put in an intrusive place. Are there any prefered standards etc?
[10:40] <sil2100> seb128: ps-generic-autopilot-release-testing uses unity straight from trunk?
[10:42] <seb128> sil2100, the daily staging ppa which is basically trunk I think
[10:46] <mzanetti> nic-doffay: ok. I've checked it out now. doesn't look bad
[10:46] <mzanetti> nic-doffay: didn't understand your question tho
[10:46] <nic-doffay> It's regarding the control tests that Saviq suggested.
[10:47] <nic-doffay> Where would an appropriate place to put all the testing components?
[10:47] <nic-doffay> mzanetti, ^
[10:47] <Saviq> nic-doffay, just next to the actual view you're testing
[10:47] <Saviq> nic-doffay, put a grid of checkbox/button | description
[10:48] <Saviq> nic-doffay, next to an Item that actually contains the tested component
[10:48] <nic-doffay> Are there any enforced standards? Because I was thinking of just putting it on the right.
[10:48] <Saviq> nic-doffay, yeah, just fine
[10:48] <mzanetti> nic-doffay: also, don't use fixed numbers for width/height but rather use units.gu()... otherwise it won't work on different DPI screens
[10:48] <Saviq> mzanetti, indeed!
[10:48] <sil2100> seb128: since it's using daily-build, the next unity will be published in the PPA tomorrow I think - it still has the 6 hours-ago version in it
[10:49] <Saviq> nic-doffay, make sure to put the actual tested components in a separate components
[10:49] <Saviq> -s
[10:49] <Saviq> and then next to it the buttons and checkboxes
[10:49] <nic-doffay> You mean to the actual test itself Saviq ?
[10:50] <sil2100> seb128: since from what I know it fetches unity once-per-day, at least that's how it was before
[10:50] <mzanetti> Saviq: is this about the checkboxes for properties as dandrader always puts in his tests?
[10:50] <Saviq> mzanetti, yup
[10:50]  * mzanetti really likes those... in case a test fails its super easy to reproduce the failure
[10:50] <mzanetti> manually
[10:50] <nic-doffay> I was planning on putting the control test item as a child of the root (UnityTestCase also being a child of the root)
[10:50] <Saviq> yup
[10:51] <Saviq> nic-doffay, in your case - put the PageHeader in a container
[10:51] <Saviq> nic-doffay, with clip: true
[10:51] <Saviq> nic-doffay, and then on the right a grid of button/checkbox | description
[10:52] <Saviq> nic-doffay, container == Item
[10:52] <Saviq> biab
[10:53] <tsdgeos> Does anyone have an opinion on https://code.launchpad.net/~michihenning/unity/cpp-warnings/+merge/157010 ?
[10:53] <tsdgeos> even a suggestion on how to fix the gpointer warning in a less ugly way?
[10:54] <nic-doffay> Saviq, yeah cool assumed the container would an Item, however what does clip: true do? I'm not familiar with that.
[10:56] <tsdgeos> mzanetti: remove the "#testedlines=301"?
[10:58] <mzanetti> tsdgeos: ack
[10:58] <mzanetti> tsdgeos: done
[10:59] <tsdgeos> mzanetti: ok, so i guess we accept that coarse approach for coverage for the moment? i.e. shall i approve?
[11:00] <mzanetti> tsdgeos: imho yes. I think its useful and at least we would need it merged to prove its usefulness/failures
[11:00] <mzanetti> Saviq: your opinion? ^
[11:06] <sil2100> Is there anyone here using precise, Unity-2D and 3 monitors at once that could verify a bug is fixed in -proposed?
[11:06] <sil2100> https://bugs.launchpad.net/unity-2d/+bug/930147
[11:16] <tsdgeos> sil2100: you really really want a small number of people :D
[11:17] <tsdgeos> sil2100: when i was working on that i used virtualbox to create 3 monitors, works pretty well
[11:18] <tsdgeos> sil2100: so i guess you could try to setup it yourself
[11:18] <sil2100> tsdgeos: oh ;) I actually tried to do a real hardware configuration for verifying that bug yesterday!
[11:18] <tsdgeos> i could do it again here but given i coded the fix that'd be cheating :D
[11:18] <sil2100> tsdgeos: since my old precise laptop has both DVI and SVGA (the round one) output
[11:19] <tsdgeos> did you suceed in actually getting the 3 outputs?
[11:19] <sil2100> tsdgeos: but sadly 2 xservers was the max I could get, I could only mix twin-view with separate x-servers and such
[11:19] <tsdgeos> right
[11:19] <om26er> popey, Hi! whats the procedure to show the autopilot test results. shall the information be added to the bug report or is it fine to add that information to the merge proposal
[11:19] <om26er> or will it just work off the record over IRC with didrocks  ?
[11:19] <tsdgeos> i have 2 external outputs here but i think i can just enable one of them at a time
[11:20] <sil2100> tsdgeos: I'll try setting it up on VB here, or ask popey to try that once he appears
[11:20] <sil2100> tsdgeos: good to know you can do that on a VM ;p
[11:25] <tsdgeos> sil2100: virtualbox lets you setup up to 64 monitors
[11:25] <tsdgeos> err screens
[11:25] <tsdgeos> not sure what would happen if you go that far :D
[11:26] <om26er> sil2100, ping
[11:28] <sil2100> om26er: pong
[11:28] <om26er> sil2100, is there an official procedure for unity/compiz sru ? I have prepared the branch and was asked to produce autopilot results to make sure no regression happened
[11:29] <om26er> sil2100, now we have the results that pope_y generated
[11:29] <om26er> sil2100, but where should those results go ?
[11:29] <sil2100> om26er: that's for precise, right? Usually when we do a precise unity/compiz release, we usually create for each a testing document on which we overview the result
[11:29] <sil2100> om26er: let me show you an example
[11:29] <om26er> sil2100, for both precise and quantal
[11:30] <sil2100> om26er: so, that's a doc for precise
[11:30] <sil2100> om26er: we usually do a diff between autopilot results from vanilla and autopilot results with the package installed
[11:31] <om26er> sil2100, things used to be much simpler back in the day ;)
[11:31] <om26er> sil2100, both with and without the changes applied have the same results for autopilot
[11:31] <sil2100> om26er: then, when needed, we either do the whole suite of manual tests or just those that could be 'related' to the issue
[11:32] <om26er> wow :O
[11:32] <sil2100> om26er: ok, so just create a testing doc like this, note there that the diff in autopilot results is empty and hm
[11:32] <sil2100> om26er: yea ;p It's not as easy as it looks like! For raring it's much simpler now ;)
[11:33] <sil2100> om26er: what bug-fix are you trying to release? Could you re-send the bug number?
[11:33] <om26er> sil2100, bug 991637
[11:33] <om26er> oem team wanted that fix released
[11:33] <om26er> https://code.launchpad.net/~om26er/ubuntu/quantal/unity/fix_991637
[11:33] <om26er> https://code.launchpad.net/~om26er/ubuntu/precise/unity/fix_991637
[11:35] <sil2100> om26er: ok, so in this case, I think it would be good if you could also do manual tests related to the launcher and note if anything got broken or not
[11:35] <sil2100> om26er: i.e. tests from the manual-tests/ directory
[11:35] <sil2100> Launcher ones
[11:36] <sil2100> And I think everyone should be happy then ;)
[11:37] <om26er> sil2100, i have precise. I can test that. Don't have quantal though
[11:37] <om26er> but i suppose thats required as well
[11:37] <sil2100> om26er: with this testing document (including the 0 diff for autopilot results and the launcher manual tests), the packaging branches and bug number(s), you can send it to the distro guys then
[11:37] <sil2100> om26er: yeah, sadly yes... I know popey has VM's for all releases, so maybe he could help once he's up and running
[11:38] <om26er> sil2100, he helped a lot already. ran all the tests on his VM
[11:38] <om26er> i will let you know where i get with this.
[11:39] <om26er> given didrocks is one of the distro guys i think he might be just happy with the autopilot tests as he said on the merge proposal
[11:39] <didrocks> om26er: this doesn't replace the manual tests
[11:39] <sil2100> om26er: ok! Sorry the process is so complicated, but after all the regressions we caused with SRU's in the past, the process had to get stricter
[11:39] <didrocks> om26er: and yeah, see what sil2100 is telling ^ :)
[11:40] <didrocks> we can't afford breaking the shell on existing release
[11:40] <sil2100> Since autopilot wasn't so good in the past, there's nothing better than the good'ol manual tests ;)
[11:40] <om26er> hope they are not too many tests
[11:40] <om26er> didrocks, sure...
[11:41] <nic-doffay> Saviq, I just did some research on the clip parameter. So basically it ties into the Geometry and enforces scissoring. Is there a particular reason you recommended it be specifically enabled for the control test in PageHeader?
[12:45] <didrocks> sil2100: hey, there are still other tests failing, mind having a look?
[12:45] <didrocks> sil2100: run 18
[12:46] <seb128> some weird stuff happening
[12:46] <seb128> like http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-ati/18/artifact/results/artifacts/unity.tests.test_hud.HudBehaviorTests.test_hud_to_dash_has_key_focus.ogv
[12:47] <seb128> firefox got spawned from nowhere
[12:47] <seb128> leading to
[12:47] <seb128> http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-ati/18/testReport/unity.tests.test_hud/HudBehaviorTests/test_hud_to_dash_has_key_focus/
[12:47] <seb128> "AssertionError: ('The following apps were started during the test and not closed: %r', [<BamfApplication 'Firefox Web Browser'>])"
[12:49] <sil2100> Really strange things are happening there
[12:49] <sil2100> Sometimes the dash doesn't show up on Super, or the application lens too
[12:50] <sil2100> And why are the lenses not searching anything for nvidia during the test_search suite?
[12:50] <sil2100> Something is badly broken, need to see the whole test result doc
[12:51] <sil2100> Ah, sorry, checked wrong build
[12:52] <sil2100> But I see the same happened for -ati
[12:52] <seb128> Trevinho, hum, http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/unity.tests.launcher.test_icon_behavior/LauncherIconsTests/test_trash_open_does_not_prevent_nautilus_to_run_Single_Monitor_/ seems like a bug of yours maybe?
[12:52] <didrocks> sil2100: same on intel
[12:52] <dandrader> is there a well-known bug about compiz crash when you start Files(nautilus) in raring?
[12:52] <seb128> Trevinho, I can confirm locally
[12:52] <seb128> dandrader, yes
[12:52] <seb128> dandrader, it's fixed in the version we are trying to land
[12:53] <dandrader> seb128, do you known the number/url?
[12:53] <didrocks> seb128: firefox is spawn with the legal noticed
[12:53] <Trevinho> seb128: let me check
[12:53] <seb128> didrocks, the nautilus one seems a real bug, I get it locally
[12:53] <Walther> Hmm. Compiz's "grid" plugin fails a bit with its cornertiling; is there going to be better support for quarter-screen splits?
[12:53] <didrocks> seb128: yeah, some with the trash changes can be impacted
[12:53] <Walther> In addition to the current half-screen split, I'd appreciate quarter splits very much at work
[12:53] <Trevinho> seb128: it works here... mhmhm
[12:53] <didrocks> the other seems to be at least firefox being spawn
[12:53] <seb128> dandrader, http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3273
[12:53] <seb128> didrocks, yes
[12:54] <Trevinho> seb128: os there a video of that?
[12:54] <Trevinho> seb128: ahh
[12:54] <Trevinho> seb128: mh I thought that it was done once without complains... Yes, need to fix AP
[12:55] <seb128> Trevinho, run "autopilot run unity.tests.launcher.test_icon_behavior.LauncherIconsTests.test_trash_open_does_not_prevent_nautilus_to_run" on your box
[12:55] <dandrader> seb128, thanks!
[12:55] <seb128> Trevinho, thanks
[12:56] <didrocks> Trevinho: do you mind looking at other failing in case of nautilus-related ones?
[12:56] <Saviq> tsdgeos, any reason why no top-approve on https://code.launchpad.net/~mzanetti/unity/phablet-deps-update/+merge/155701 ?
[12:57] <mzanetti> Saviq: no particular reason... we pinged you a while ago and as you didn't reply it was left as is
[12:58] <Saviq> nic-doffay, so that it doesn't draw outside of its container, is all
[12:58] <Saviq> mzanetti, yeah, just going through the back log
[12:59] <Saviq> mzanetti, approved
[12:59] <mzanetti> cheers
[12:59] <Trevinho> didrocks: are them all related to this?
[13:00] <didrocks> Trevinho: probably not, some are due to firefox being spawn
[13:00] <didrocks> Trevinho: but would be nice to check if there are more than one related to your change
[13:02] <Saviq> mzanetti, tsdgeos, I'm going into a meeting now, might not make it for the standup, you'll manage, I hope :)
[13:03] <mzanetti> Saviq: ofc
[13:04] <Saviq> tsdgeos, mzanetti, can you take a look at https://jenkins.qa.ubuntu.com/job/unity-phablet-raring-i386-ci/157/console please
[13:04] <sil2100> I wonder what caused the legal screen to appear
[13:04] <Saviq> tsdgeos, mzanetti, it's happened in a bunch of CI runs now
[13:04] <Saviq> not sure what introduced that
[13:05] <sil2100> Maybe the previous test did something
[13:05] <tsdgeos> Saviq: maybe the change i approved for cmake changes, but otoh that was approved  by ci and autloanding
[13:06] <tsdgeos> speaking about http://bazaar.launchpad.net/~unity-team/unity/phablet/revision/538
[13:06] <Saviq> tsdgeos, yeah
[13:06] <Saviq> tsdgeos, here's a related comment https://code.launchpad.net/~michihenning/unity/phablet-unity-api-merge-tests/+merge/157326/comments/344389
[13:06] <Saviq> but it's happened in https://code.launchpad.net/~michihenning/unity/phablet-unity-api-whitespace-test/+merge/157329 too
[13:06] <didrocks> sil2100: so, you are more used to autopilot tests than I am
[13:07] <didrocks> sil2100: but what I see is:
[13:07] <didrocks> the legal notice was clicked (see other tests, the ! instead of the text)
[13:07] <didrocks> the dash is maximized
[13:07] <didrocks> which doesn't seem to be the case previously, right?
[13:07] <didrocks> so I think what happened is:
[13:07] <didrocks> - the dash was maximized for X reasons
[13:08] <didrocks> - we clicked on the bottom right of the screen in a test to dismiss the dash
[13:08] <didrocks> -> this in turned clicked on the legal notice
[13:08] <didrocks> so that root cause we must find is what made the dash to be maximized
[13:08] <sil2100> didrocks: that's similar to the thing I'm trying to find in the previous tests - so I think this theory might be the right thing ;)
[13:09] <didrocks> sil2100: keep us posted
[13:09] <mzanetti> tsdgeos: are you on that cmake issue or should I take care about it?
[13:09] <tsdgeos> mzanetti: if you can take care better
[13:10] <mzanetti> ack
[13:10] <kgunn> mzanetti: welcome back!
[13:10] <sil2100> didrocks: btw. is the generic job executed differently than the previous unity release test jobs?
[13:10] <mzanetti> kgunn: hi :)
[13:11] <didrocks> sil2100: yeah, the job is basically the "autopilot" job, it's used by the oif, indicator, unity stacks with different parameters
[13:11] <didrocks> sil2100: last run was with the 100scopes ppa
[13:11] <didrocks> which isn't merged with latest trunk content but last unity release in ubuntu
[13:13] <fginther> didrocks, rev 149 deployed
[13:14] <didrocks> thanks fginther, btw, the --pin-ppa was important and it's now fixed :)
[13:16] <tsdgeos> dednick: i was wondering why you used 4 different UnityTestCase in https://code.launchpad.net/~nick-dedekind/unity/phablet-test-indicator-row/+merge/157070
[13:16] <fginther> didrocks, I saw that jibel fixed it, that was on my todo list for today.  For my education, what exactly does that script do?
[13:16] <didrocks> fginther: creating a file for telling "this ppa in argument has absolute priority over distro"
[13:16] <didrocks> "even if versions are lower than what is in the distro"
[13:17] <didrocks> and as we really want to test the ppa content… ;)
[13:17] <sil2100> didrocks: uno momento, will just finish lunch
[13:18] <didrocks> sil2100: sure ;)
[13:18] <fginther> didrocks, ah thanks
[13:18] <didrocks> sil2100: we have a big crasher in distro with nautilus, that's why we need to release it today FYI
[13:18] <didrocks> fginther: something else
[13:18] <didrocks> fginther: if the installer is failing
[13:18] <didrocks> then the rsync part is failing as well
[13:18] <didrocks> which is confusing I guess
[13:19] <didrocks> can you add || true to the rsync for collecting files?
[13:19] <fginther> didrocks, yes
[13:20] <fginther> didrocks, otherwise, is the generic job working as you expect?
[13:20] <didrocks> fginther: thanks! https://jenkins.qa.ubuntu.com/job/ps-generic-autopilot-release-testing/15/label=autopilot-nvidia/console is a good example
[13:20] <didrocks> fginther: otherwise, sounds perfect up to now :)
[13:20] <didrocks> fginther: we should keep the other jobs for 2 more days I guess
[13:20] <didrocks> fginther: and then we can kill them
[13:20] <fginther> didrocks, I will be sure to archive them, just in case
[13:21] <didrocks> fginther: yeah, and having the -generic job in a vcs somewhere?
[13:21] <didrocks> for the scripts and so on
[13:22] <fginther> didrocks, mhmm jobs in vcs... that's another story...
[13:22] <didrocks> fginther: the template
[13:22] <didrocks> fginther: as you have templates that we are deploying
[13:22] <didrocks> but yeah, in nutshell, it's really great to be able to only rely on one preseed and one jobs nowadays :)
[13:24] <fginther> didrocks, of course, that's an easier solution then what I was thinking
[13:25] <didrocks> fginther: as long as we have just one (well 3, one per config) hw, it's good. Maybe we'll need another job for the "apps" if they can run in a vm alone
[13:25] <didrocks> fginther: but yeah, let's try to minimize and having that parameterized :)
[13:26] <seb128> did anyone do changes to the unity panel service recently?
[13:26] <fginther> didrocks, we already do some app in a vm testing on the ci side. Definitely something to discuss in the future
[13:27] <larsu_> seb128: how recently?
[13:27] <seb128> larsu_, this week
[13:27] <didrocks> fginther: I think this is a topic for next week in fact :)
[13:28] <larsu> seb128: phew, not me then :)
[13:28] <didrocks> fginther: with touch apps ported by mterry, kenvandine, robru and cyphermox to daily releases ;)
[13:28] <fginther> didrocks, right!
[13:28] <seb128> larsu, ;-)
[13:29] <dandrader> tsdgeos, jeez... seems ld segfaulted while linking libFakeHudClientQml.so. Have you ever something like that before? https://jenkins.qa.ubuntu.com/job/unity-phablet-raring-armhf-ci/164/console
[13:30] <tsdgeos> brrr
[13:30] <dednick> tsdgeos: just wanted to separate the different test areas. there were alot of tests which were testing very similar things.
[13:30] <tsdgeos> nope
[13:30] <tsdgeos> dandrader: tried a retrigger?
[13:30] <tsdgeos> dednick: oki
[13:45] <Cimi> Saviq, what makes sense to write tests now?
[13:45] <Cimi> Saviq, listviewwithpageheader wasn't supposed to be refactored?
[13:45] <Saviq> Cimi, yes, greyback will be on it
[13:46] <Cimi> ok
[13:46] <Saviq> once he's done with usability
[13:46] <tsdgeos> mzanetti: the keyClick with chars was merged finally into Qt :)
[13:46] <tsdgeos> their tests are ultra unstable, had to run like 3 times to get it merged in :D
[13:46] <mzanetti> tsdgeos: \o/ will it make it into 5.1?
[13:47] <tsdgeos> mzanetti: yep, was merged into the stable branch that is supposed to be what will be 5.1
[13:47] <mzanetti> tsdgeos: awesome, thanks
[13:47] <Cimi> Saviq, openeffect?
[13:47] <mzanetti> tsdgeos: we have now 100+ qml tests :)
[13:47] <Cimi> Saviq, the application ones will be killed after MIR I think
[13:47] <mzanetti> all green too
[13:47] <Saviq> Cimi, there's a MP from paul
[13:47] <Cimi> ok
[13:48] <Saviq> Cimi, redone, rather
[13:49] <tsdgeos> mzanetti: grand :-)
[13:53] <tsdgeos> kgunn: Saviq: so what kind of review where you thinking for "review high-risk components (Carousel, ListViewWithPageHeader, FilterGrid, SortFilterProxyModel)" ?
[13:53] <kgunn> Cimi: meant to say...welcome back to you too
[13:53] <Cimi> kgunn, thanks :)
[13:54] <kgunn> tsdgeos: not sure...that's was Saviq's
[13:54] <Saviq> tsdgeos, I had just a close review of them in mind to see where we can improve, what's missing
[13:54] <Saviq> tsdgeos, there's definitely tests missing for the SFPM
[13:54] <kgunn> tsdgeos: didn't gunter take care of Carousel
[13:54] <Saviq> tsdgeos, but LVWPH is a separate topic
[13:54] <Saviq> kgunn, we had to revert
[13:54] <Saviq> tsdgeos, so here's one ^
[13:55] <Saviq> tsdgeos, finding out what's the crash
[13:55] <Saviq> tsdgeos, and fixing / filing a bug with QT
[13:55] <Cimi> Saviq, tile.qml?
[13:55] <kgunn> tsdgeos: LVWPH is on greyback's todo list
[13:55] <Saviq> Cimi, sure, sounds like a small candidate
[13:55] <Cimi> Saviq, I can't see others :D
[13:56] <tsdgeos> kgunn: Saviq: ok, i'll split it into two at least giving LVWPH to greyback
[13:56] <Saviq> Cimi, we have a coverage review planned for Monday
[13:56] <Cimi> good
[13:56] <sil2100> https://code.launchpad.net/~sil2100/unity/revert_3276/+merge/157366
[13:56] <kgunn> tsdgeos: yeah...LVWPH is there already in the Dash bp
[13:56] <Saviq> Cimi, hope to come up from there with a list of testing-todo
[13:57] <kgunn> tsdgeos: feel free to modify/split out the SFPM, filtergrid & Carousel
[13:57] <greyback> tsdgeos: yep, send it my way. The Usability stuff has finished up this afternoon, so I'm slowly getting back into it
[13:57] <kgunn> greyback: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-dash
[13:57] <kgunn> its actually in that one ^
[13:58] <greyback> kgunn: ok, I'll move my postponed tasks to the month6 milestone and work on them
[13:58] <greyback> s/move/copy/
[13:58] <kgunn> greyback: cool...btw, thanks for the extra effort on usability
[13:59] <greyback> kgunn: move or copy actually?
[13:59] <kgunn> greyback: we're going with move
[13:59] <kgunn> greyback: each one has a vice & virtue in the tool
[13:59] <greyback> kgunn: yeah was pretty tight deadline :)
[13:59] <greyback> kgunn: move it is
[13:59] <kgunn> greyback: and there is no canonical convention...which i find strange :)
[14:00] <greyback> kgunn: convention....canonical... *confused*
[14:00] <kgunn> :))
[14:01] <tsdgeos> Saviq: any opinion on the TO_GPOINTER thing of https://code.launchpad.net/~michihenning/unity/cpp-warnings/+merge/157010 ?
[14:01] <tsdgeos> oh my
[14:02] <tsdgeos> me and gerry clashed on blueprint edition :D
[14:02] <greyback> oO
[14:02] <tsdgeos> you undid what i did
[14:02] <Saviq> tsdgeos, we gotta do what we gotta do
[14:02] <greyback> oh you're kidding
[14:02] <tsdgeos> nope
[14:02] <tsdgeos> :D
[14:02] <tsdgeos> your last diff is
[14:02] <tsdgeos> - [aacid] review high-risk components (Carousel, FilterGrid, SortFilterProxyModel): TODO
[14:02] <tsdgeos> - [gerboland] review high-risk components (ListViewWithPageHeader): TODO
[14:02] <tsdgeos> + [aacid] review high-risk components (Carousel, ListViewWithPageHeader, FilterGrid, SortFilterProxyModel): TODO
[14:02] <tsdgeos> which is exactly the reverse of my change
[14:03]  * tsdgeos edits again
[14:03] <greyback> tsdgeos: that's appalling the tool lets that happen
[14:03] <tsdgeos> it is
[14:03] <tsdgeos> Saviq: ok
[14:04] <Saviq> greyback, tsdgeos, yeah, been there, done that ;)
[14:16] <seb128> Trevinho, any look getting that unity/nautilus test fixed?
[14:16] <seb128> Trevinho, we would like to get unity landing today to fix the segfault on nautilus closing and we need tests to pass for that ;-)
[14:19] <Trevinho> seb128: yes, sure... i've been busy until now to make the indicator branches to land, now they're going... So I've time for it :)
[14:20] <Trevinho> seb128: also can we get a decision about https://bugs.launchpad.net/unity/+bug/1152477 ? doc team gave the +1... It would be nice to have and really it has low impact
[14:20] <Trevinho> seb128: I've asked on #ubuntu-release, but I got nothing
[14:21] <seb128> Trevinho, you got +1 from the documentation team, let me check with the release guys, should be fine
[14:21] <seb128> oh, andyrock just asked there
[14:21] <seb128> I will make sure he gets a reply by doing direct ping on individuals if needed ;-)
[14:24] <Trevinho> seb128: nice
[14:27] <dandrader> Saviq, should be good to go now: https://code.launchpad.net/~dandrader/unity/phablet_dashapp_dead_code/+merge/157153
[14:27] <Saviq> dandrader, right
[14:27]  * Saviq needs more threads
[14:27] <dandrader> :)
[14:28] <Saviq> dandrader, did you kick jenkins into trying again?
[14:28] <dandrader> Saviq, I still didn't setup my VPN on raring
[14:28] <Saviq> dandrader, k, I'll do that
[14:28] <dandrader> Saviq, thanks!
[14:35] <tsdgeos> argg
[14:35] <tsdgeos> someone approved the thing that builds in a builddir and now run doesn't work
[14:36] <nic-doffay> Just merged trunk with my branch and am getting this any ideas? https://pastebin.canonical.com/88536/
[14:37] <ChrisTownsend> sil2100: Hi
[14:37] <tsdgeos> nic-doffay: an apt-get failure?
[14:37] <nic-doffay> that's right.
[14:38] <nic-doffay> Have one of the packages been removed?
[14:39] <tsdgeos> nic-doffay: what are you running?
[14:39] <nic-doffay> quantal
[14:39] <tsdgeos> i mean which command?
[14:40] <nic-doffay> ./build -s
[14:40] <Saviq> nic-doffay, remove unity-team/staging ppa
[14:40] <nic-doffay> Thanks Saviq
[14:40] <nic-doffay> Is a remove ok
[14:40] <nic-doffay> or a total purge?
[14:40] <Saviq> I think it was "decomissioned"
[14:41] <Saviq> nic-doffay, you can't purge if there ppa isn't there I'm afraid
[14:41] <sil2100> ChrisTownsend: hello!
[14:41] <Saviq> nic-doffay, so just drop the .list file from /etc/apt/sources.list.d
[14:41] <Saviq> nic-doffay, and pray ;)
[14:41] <sil2100> ChrisTownsend: any ideas about the regression potentials?
[14:41] <tsdgeos> https://code.launchpad.net/~aacid/unity/follow_the_binary/+merge/157386 anyone?
[14:42] <tsdgeos> Saviq: nic-doffay: dednick: mzanetti: greyback: ↑↑↑
[14:42] <Saviq> tsdgeos, on it
[14:42] <nic-doffay> Will have a look now tsdgeos
[14:42] <ChrisTownsend> sil2100: I think the regression potential is very low.  Marco is also in agreement with this as he wrote the original code that has been in trunk for a while now.
[14:43] <Trevinho> sil2100, ChrisTownsend: yes no regressions so far... One possible regression is launching unity from terminal or killing it before starting it again and could cause undecorated-windows when they were maximized
[14:43] <Trevinho> sil2100, ChrisTownsend but it's very remote and only when hacking with it
[14:44] <sil2100> ChrisTownsend, Trevinho: ok!
[14:44] <nic-doffay> Saviq, out of interest why was Staging killed?
[14:44] <dednick> tsdgeos: ? why is it in builddir? shouldnt follow CMAKE_INSTALL_DATADIR?
[14:44] <Saviq> nic-doffay, dunno
[14:44] <sil2100> ChrisTownsend: about that one additional fix related to webapps - is it fixed properly in raring already?
[14:44] <Saviq> nic-doffay, but we got rid of staging PPAs all over
[14:45] <ChrisTownsend> sil2100: Yes, it is.  I put it in some time ago.
[14:45] <Saviq> nic-doffay, we're landing straight into distro
[14:45] <Saviq> nic-doffay, and you can grab the debs from CI
[14:45] <sil2100> ChrisTownsend: need to re-read the bug description ;)
[14:45] <tsdgeos> dednick: it's where the ./build script now puts it, Jussi changed it there and whoever did the review forgot the run script
[14:45] <ChrisTownsend> sil2100: Heh, no worries
[14:48] <dednick> tsdgeos: ah. got latest just before that change.
[14:49] <ChrisTownsend> sil2100: Do you have any ideas when the next Unity SRUs should land for 12.04 and 12.10?
[14:49] <kgunn> nic-doffay: Saviq ...just fyi, Pete Woods will be doing the greeter backend
[14:50] <nic-doffay> Ok kgunn . I'm assuming we'll hear more about this in the meeting on Monday?
[14:50] <kgunn> nic-doffay: i'd think so...just letting you know
[14:50] <Saviq> kgunn, k, we'll need to define the shell-facing API, even though it should be relatively simple
[14:52] <kgunn> Saviq: ok, maybe we should use a unit test to help define that :)
[14:52] <Saviq> kgunn, ;D
[15:01] <Saviq> anyone else in #gnome@gimpnet? ;)
[15:02] <sil2100> ChrisTownsend: not yet, but we'll try to push them out in the nearest time, as soon as possible
[15:02] <sil2100> ChrisTownsend: I'll get back to you once we have it planned out
[15:02] <ChrisTownsend> sil2100: Yes, please let me know.  Thanks!
[15:18] <sil2100> ChrisTownsend: I noticed that jenkins had some problems with https://code.launchpad.net/~townsend/unity/fix_1070715-6.0/+merge/155479 <- could you check the last jenkins error message?
[15:18] <sil2100> Since it seems it's failing somewhere around test_switcher_model.cpp
[15:19] <ChrisTownsend> sil2100: Yeah, I fixed that and pushed the change to the MP branch.
[15:19] <ChrisTownsend> sil2100: The MP just needs re-approved.
[15:21] <nic-doffay> Looks like I did a bad merge somewhere along the line, getting this compilation issue: https://pastebin.canonical.com/88548/
[15:21] <sil2100> ChrisTownsend: thanks! Re-approving
[15:21] <ChrisTownsend> sil2100: Thanks!
[15:25] <Trevinho> seb128: https://code.launchpad.net/~3v1n0/unity/autopilot-nautilus-unregister/+merge/157409 (and maybe sil2100)?
[15:28] <seb128> Trevinho, thanks
[15:31] <tsdgeos> tedg: see nic-doffay's log ↑↑↑
[15:31] <nic-doffay> I think I've found it.
[15:31] <nic-doffay> Just waiting for the compile.
[15:31] <tsdgeos> ok
[15:39] <Saviq> tsdgeos, just went through the FIXMEs, grand work
[15:39] <tsdgeos> :-)
[15:40] <kgunn> dednick: btw, which fixme did you happen to nail ?
[15:41] <kgunn> suppose i could look at mp's...
[15:42] <kgunn> nvmd...got it
[15:42] <dednick> kgunn: ok. was just about to paste :)
[15:46] <seb128> sil2100, mterry: any opinion on https://code.launchpad.net/~3v1n0/unity/autopilot-nautilus-unregister/+merge/157409
[15:46] <seb128> Trevinho, why can't you use the register_known_application()?
[15:46] <mterry> seb128, looking
[15:46] <seb128> mterry, it's to fix http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/unity.tests.launcher.test_icon_behavior/LauncherIconsTests/test_trash_open_does_not_prevent_nautilus_to_run_Single_Monitor_/
[15:47] <Trevinho> seb128: since we need to unregister it at the end of the test, I'd prerfer not to duplicate the efforts and adding an utility function
[15:47] <Trevinho> that does registration and unregistration
[15:48] <mterry> seb128, seems reasonable
[15:48] <mterry> a little special casy for 2 uses
[15:48] <seb128> I don't have a strong opinion, it seems a bit weird to special case nautilus
[15:48] <mterry> but may be useful more often in future
[15:49] <mterry> seb128, you think maybe have the util function take a parameter?
[15:49] <seb128> mterry, if that applies to other apps, yes
[15:49] <seb128> Trevinho, what is special about nautilus?
[15:49] <mterry> Trevinho, do you ever use other apps?
[15:49] <Trevinho> mterry, seb128: I've to write other tests for nautilus, and that will happen...
[15:49] <seb128> is that likely to be useful in other cases?
[15:49] <Trevinho> seb128: nautilus is the file-manager, is not just an app :)
[15:50] <seb128> ok, fair enough
[15:50] <Trevinho> seb128: also it's better not to rewrite the same strings twice or more...
[15:50] <seb128> Trevinho, mterry: that's good enough for me, I'm flagging it approved, thanks ;-)
[15:50] <bschaefer> :(, sorry, when I had made that fix earlier all seemed well!
[15:50] <Trevinho> nice ;)
[15:50] <didrocks> bschaefer: you meant *those* fixes :-)
[15:50] <didrocks> hey bschaefer!
[15:50] <seb128> bschaefer, hey, which one, the dash closing one or the test one? ;-)
[15:51] <bschaefer> didrocks, well it fixed 1 test, and made 3 more :), but yeaah
[15:51] <seb128> bschaefer, we had to revert 2 commits of yours today
[15:51] <bschaefer> geez what?
[15:51] <didrocks> bschaefer: and made 200+ failures :p
[15:51]  * bschaefer goes into the corner
[15:51] <seb128> bschaefer, http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3277 as well
[15:52] <didrocks> bschaefer: more seriously, when you add tests and modify the behavior, please rerun at least the autopilot area you touched ;)
[15:52] <bschaefer> seb128, dang...i was fixing up a different branch, there. Thanks for getting on it quickly though!
[15:53] <Trevinho> didrocks: that's something very invasive, you know, right? :)
[15:53] <bschaefer> didrocks, yeah, i try to but sometimes I don't have an hour of downtime :(
[15:53] <Trevinho> at least, without having another machine just for AP
[15:53] <didrocks> Trevinho: guest session :)
[15:53] <didrocks> bschaefer: yeah, but the consequence is that we lost several hours today
[15:53] <seb128> bschaefer, yw, sorry about the reverts, but we are trying to land an unity update to fix the "segfaults when closing nautilus" issue that is in raring atm, so we tried to get tests to turn green before european eod
[15:54] <bschaefer> didrocks, very true, shortcuts are never good, sorry!
[15:54] <didrocks> bschaefer: so no blame, just being a little bit more careful in the future :)
[15:54] <bschaefer> yeah :)
[15:54] <didrocks> bschaefer: so, the upload will close your bugs though
[15:54] <didrocks> bschaefer: we'll need to reopen them
[15:54] <bschaefer> seb128, no worries! The seg fault is waay more important
[15:54] <didrocks> to not loose tracks
[15:54]  * bschaefer goes to reopen bugs
[15:54] <didrocks> bschaefer: it's not uploaded yet!
[15:54] <didrocks> bschaefer: the tests are still running after the second revert ;)
[15:55] <bschaefer> didrocks, o well, ill keep an eye on when it goes through then :)
[15:55] <seb128> andyrock, Trevinho: you got your UIFe acked
[15:55] <didrocks> bschaefer: ok, let's both keep an eye on it in case we missed it :)
[15:55] <andyrock> seb128, thanks :)
[15:55] <bschaefer> didrocks, sounds good :)
[15:57] <Trevinho> seb128: yes, thanks I was just reading it
[15:57] <Trevinho> seb128: it wasn't "mine", a community guy did it, but I do care about contributions! :)
[15:57] <seb128> ;-)
[16:05] <nic-doffay> tsdgeos, no win on that compile issue btw
[16:06] <nic-doffay> My cmake diff is minor too: https://pastebin.canonical.com/88553/
[16:12] <tsdgeos> nic-doffay: you have hud twice in there?
[16:12] <nic-doffay> tsdgeos, doh!
[16:12] <nic-doffay> Do I?
[16:12] <nic-doffay> Just noticed it!
[16:13] <nic-doffay> That's weird though, I removed it and tried compiling again to no avail (the most recent attempt)
[16:13] <nic-doffay> Let me double check again...
[16:21] <sil2100> bschaefer: hi!
[16:21] <sil2100> You saw my revert, right?
[16:21] <bschaefer> sil2100, yup! Sorry about all the problems!
[16:29] <sil2100> bschaefer: no problem ;) Just hope you don't mind we so quickly reverted it, but it seemed as the fastest way ;)
[16:30] <sil2100> bschaefer: good luck on finding the root cause!
[16:30] <sil2100> Have a nice weekend guys!
[16:30] <bschaefer> sil2100, o no that was the best way atm, cause if what I did caused ~200 problems...yeeah
[16:30] <bschaefer> dang
[16:46] <mzanetti> Saviq: u around?
[16:55] <Saviq> mzanetti, yeah
[16:55] <greyback> nice weekend folks!
[16:55] <mzanetti> greyback: have fun!
[16:55] <greyback> mzanetti: you too
[16:55] <mzanetti> Saviq: some good and some bad news for you
[16:56] <Saviq> greyback, cheers
[16:56] <Saviq> mzanetti, just for me?
[16:56] <mzanetti> Saviq: good ones first: http://s-jenkins:8080/job/unity-phablet-qmluitests/
[16:56] <mzanetti> we have now stats included for C++ code
[16:56] <mzanetti> Saviq: the bad news is that "make sometests" still stops as soon as the first test fails
[16:58] <Saviq> mzanetti, hmm because it's a target, and if anything for a target fails the target fails...
[16:58] <mzanetti> yeah...
[16:58] <mzanetti> googling didn't give a quick solution for this
[16:58] <mzanetti> maybe our cmake master renato has a clue
[17:00] <Saviq> mzanetti, yeah, it'd be best if we could have multiple test targets, right?
[17:00] <mzanetti> Saviq: hmm... each test a single target and then call "make alltests" ?
[17:00] <Saviq> mzanetti, well, that would mean alltests is a target...
[17:00] <Saviq> mzanetti, so still fail == stop
[17:00] <mzanetti> right...
[17:01] <Saviq> mzanetti, but with add_test() it's not like that
[17:01] <Saviq> mzanetti, the quickest I can think of is having a -DCMAKE_WHATEVER_VAR
[17:02] <Saviq> mzanetti, and add_test() based on that var
[17:02] <Saviq> mzanetti, but yeah, let's talk with some CMake gurus next week
[17:02] <mzanetti> ok
[17:02] <kgunn> mzanetti: is what you guys are talking about why the test report doesn't look correct?
[17:03] <mzanetti> kgunn: yeah... as soon as one test fails, execution stops
[17:03] <kgunn> have a good weekend
[17:04] <Saviq> kgunn, yeah, the difference between the testing framework in CMake and generic targets
[17:04] <Saviq> kgunn, is that if any of the dependencies of a target fails, it stops
[17:04] <Saviq> kgunn, which is not the case for tests
[17:05] <kgunn> Saviq: totally...should be isolated
[17:05] <Saviq> kgunn, but we need different test suites, so we can't just add everything as a test, 'cause it will fail in jenkins
[17:05] <Saviq> during package building
[17:05] <Saviq> we'll sort it out :)
[17:06] <kgunn> Saviq: thanks...it did solve that mystery for me, .e.g why
[17:06] <Saviq> kgunn, yeah
[17:06] <kgunn> the test report looked wrong
[17:09] <Saviq> kgunn, have a nice weekend, talk to you Mondat
[17:09] <Saviq> Monday, even
[17:10] <kgunn> you too!
[17:24] <mzanetti> yay! coverage is climbing :)
[17:24] <nic-doffay> Looks like that's a day for me. Have a good weekend all.
[17:28] <mzanetti> Saviq: so I don't feel useless today, here's a MP before I'm off for the weekend: https://code.launchpad.net/~mzanetti/unity/more-stats/+merge/157441
[20:22] <Saviq> bschaefer, hey, you need to make sure to look through pending merges
[20:22] <Saviq> bschaefer, https://code.launchpad.net/~michihenning/unity/phablet-unity-api-merge-1/+merge/156746
[20:23] <Saviq> bschaefer, that fixes the warnings you posted a branch for (and then some)
[20:23] <bschaefer> Saviq, right, that would be a good idea
[20:23] <Saviq> actually not that branch...
[20:23] <bschaefer> Saviq, let me reject those branchs that are dups
[20:24] <bschaefer> Saviq, sometimes those larger branchs are hard to go through quickly, I try to keep mine small...
[20:24] <Saviq> bschaefer, yeah, we're kind of in a transition phase
[20:24] <Saviq> so we'll have some big diffs coming
[20:25] <Saviq> this one https://code.launchpad.net/~michihenning/unity/fix-c-linkage-1163719/+merge/156751
[20:25]  * bregma thinks big diffs are a negative contribution to overall code quality
[20:25] <bschaefer> Saviq, cool, im actually just kind of trying to wrap my head around the new code base, and qml :)
[20:25] <bschaefer> Saviq, o nice
[20:25] <Saviq> bregma, +1
[20:25] <bregma> bschaefer, how big was that 100-scopes MP?
[20:25] <bschaefer> bregma, ugg...50,000 lines
[20:26] <bschaefer> Saviq, yeah, nice! Hes is a bit more clear on whats being assigned as well :)
[20:27] <Saviq> bschaefer, that particular MP should be smaller - it should have a prerequisite
[20:27] <Saviq> but I'm not sure now whether it's safe to make the other one a prereq, will pick that up with the author next week
[20:27] <bschaefer> Saviq, oo, forgetting to that can increase the diff a bit :)
[20:28] <Saviq> bschaefer, it's not even about forgetting, people are still learning the ways :)
[20:28] <bschaefer> Saviq, that as well! There always seems to be a bunch to learn :)
[20:29] <bschaefer> Saviq, also, that gtest/gmock linked was much simpler! I might go changed unity...
[20:29] <Saviq> bschaefer, about that
[20:29]  * bschaefer is also unsure what the goal was with gtest/gmock with the phablet
[20:29] <Saviq> bschaefer, couldn't you just use ${CMAKE_CURRENT_BINARY_DIR}/gtest to build it in wherever we actually build the code in?
[20:30] <Saviq> bschaefer, right now there's barely any c++ code in lp:unity/phablet
[20:30] <Saviq> bschaefer, but that's going to change
[20:30] <bschaefer> Saviq, right, im also pretty new to cmake as well :)
[20:30] <bschaefer> Saviq, I saw some changes land that build things in builddir now which is nicer then what I had
[20:31] <Saviq> bschaefer, we're going to keep all the API implementations in lp:unity-to-be
[20:31] <Saviq> (not literally)
[20:31] <bschaefer> :), the libunity stuff?
[20:31] <Saviq> yeah, the new libunity
[20:31]  * bschaefer has a lot to learn about the current stack
[20:32] <Saviq> to avoid breakage / incompatibility / desynchronization
[20:32] <bschaefer> yeah, sounds good. That might be a better place for the gtest stuff as well
[20:32] <Saviq> which we've had too many  in the past
[20:32] <bschaefer> is that what you were talking about with the new c++ stuff landing? Or different c++ stuff?
[20:33] <Saviq> bschaefer, about gtest... so yeah, actually we have an
[20:33] <Saviq> https://code.launchpad.net/~michihenning/unity/phablet-unity-api-merge-tests/+merge/157326
[20:33] <Saviq> bschaefer, yeah the shell will become just a part of the project
[20:33] <Saviq> bschaefer, those big dumps are gearing towards that happening
[20:34] <bschaefer> Saviq, well sweet, i can reject my gtest branch as well :), michi is getting  a lot of good stuff ready :)
[20:34]  * Saviq tries if adding the prerequisite will work
[20:34] <bschaefer> Saviq, cool, lots of things happening :), I just started looking at the code yesterday soo im still picking up where things are...
[20:35] <bschaefer> Saviq, is there a current bug tracker for the phablet? Cause unity/phablet had like 4 bugs in it
[20:44] <Saviq> bschaefer, the public tracker is under lp:touch-preview-images
[20:44] <Saviq> for now
[20:45] <bschaefer> Saviq, cool, and looking through the other merges, my only MP left that I don't think anyone has done is this:
[20:45] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/open-effect-type-error-null-fix/+merge/157218
[20:49] <Saviq> bschaefer, approved, thanks
[20:49] <Saviq> afk
[20:49] <bschaefer> Saviq, cool, thanks!
[20:49] <bschaefer> c ya