[07:04] <Saviq> Cimi, ping
[07:34] <tsdgeos> mzanetti: any idea of why the difference between https://jenkins.qa.ubuntu.com/job/unity-phablet-quantal-armhf-ci/564/console and https://jenkins.qa.ubuntu.com/job/unity-phablet-quantal-i386-ci/563/consoleFull ?
[07:39] <mzanetti> tsdgeos: the only thing I could imagine right now is that the main -ci job was started, the i386 started immediately while the arm one was waiting in the queue. in the meantime you pushed something that changed the codebase
[07:39] <mzanetti> or the other way round
[07:39] <mzanetti> if you say no, you didn't change the code, I'm lost too
[07:40] <tsdgeos> ah, that might make sense
[07:40] <tsdgeos> the modeltest was pushed a bit later
[07:40] <mzanetti> huh... luckily... those kind of things really scare me
[07:40] <tsdgeos> so yeah
[07:41] <tsdgeos> what do we do here?
[07:41] <tsdgeos> Saviq: ping?
[07:41] <Saviq> tsdgeos, here
[07:41] <Saviq> looking
[07:41] <tsdgeos> Saviq: for the qmlsortfilterproxymodel thing, i've added a class named modeltest that comes from Qt itself, and does lots of "nasty" things to the model, to make sure it still works
[07:41] <tsdgeos> Saviq: the copyright checked is complaining
[07:42] <tsdgeos> checked/checker
[07:42] <Saviq> tsdgeos, that's because you didn't include the actual license
[07:42] <tsdgeos> here the MR https://code.launchpad.net/~aacid/unity/sortfilterproxymodelqml_split/+merge/159174
[07:42] <Saviq> tsdgeos, $QT_BEGIN_LICENSE:LGPL$
[07:42] <tsdgeos> Saviq: well I copied the file verbatim from the repos
[07:42] <Saviq> tsdgeos, exactly
[07:42] <Saviq> tsdgeos, you need to take it from a tarball
[07:43] <Saviq> where that var is replaced with the actual license
[07:43] <Saviq> tsdgeos, but then...
[07:43] <Saviq> tsdgeos, can we actually put it with our code?
[07:44] <tsdgeos> it's LGPL
[07:44] <tsdgeos> i don't see why not
[07:45] <tsdgeos> what's your concern?
[07:48] <Saviq> tsdgeos, well, it's tests, so we're not really going to distribute it in binary to anyone
[07:50] <Saviq> tsdgeos, but IANAL...
[07:50] <tsdgeos> still
[07:50] <Saviq> tsdgeos, at the very least, update debian/copyright
[07:50] <tsdgeos> LGPL is just compatible with everything we use
[07:50] <Saviq> tsdgeos, not if we later want to ship it under a commercial license
[07:51] <Saviq> +or need
[07:51] <tsdgeos> it is still commercial "friendly"
[07:51] <tsdgeos> just requires you to release the changes to that file
[07:51] <tsdgeos> which are 0
[07:51] <tsdgeos> and as you said, it's a test, we don't even need to distribute it binarily to people
[07:52] <tsdgeos> Saviq: i downloaded the tarball, the file is exactly the same, still hsa that  $QT_BEGIN_LICENSE:LGPL$
[07:52] <Saviq> tsdgeos, huh
[07:52] <tsdgeos> well, what did you expect?
[07:52] <tsdgeos> the license is already there
[07:53] <tsdgeos> lines 17 and down
[07:53] <Saviq> ah ok
[07:53] <Saviq> so $...$ are just markers
[07:53] <Saviq> not vars
[07:54] <tsdgeos> yep
[07:54] <Saviq> tsdgeos, then we need to add a licensecheck-compatible line in the comment there
[07:55] <tsdgeos> that'd be modifying the file and meaning we have to distribute the changes :D
[07:55] <tsdgeos> oh actually no
[07:55] <tsdgeos> we can assume gpl3
[07:55] <tsdgeos> and since it's a test who cares
[07:55] <Saviq> and the header is not under copyright
[07:57] <Saviq> tsdgeos, apt-get install devscripts
[07:57] <Saviq> tsdgeos, and make the copyright header pass
[07:57] <Saviq> +test
[07:57] <Saviq> tsdgeos, and run tests locally before submitting :P
[07:57] <Saviq> at least the test target
[07:57] <tsdgeos> sure
[07:58] <tsdgeos> i'd tell you i had done that
[07:58] <tsdgeos> but i didn't
[07:58] <tsdgeos> but still, it passes
[07:58] <tsdgeos> http://paste.kde.org/~tsdgeos/726206/
[07:58] <tsdgeos> otoh don't see any copytight check in there
[07:58] <Saviq> tsdgeos, right, because it's not merged yet
[07:59] <Saviq> tsdgeos, the copyright check is part of jenkins jobs for now
[07:59] <tsdgeos> Saviq: totally my fault for not running the tests
[07:59] <tsdgeos> i see
[08:00] <Saviq> tsdgeos, gotcha ;)
[08:00] <Saviq> tsdgeos, but you can use licensecheck from devscripts
[08:00] <tsdgeos> yep
[08:00] <Saviq> tsdgeos, something like `licensecheck -r . | grep -v -F ./builddir | grep "No copyright"`
[08:00] <Saviq> the .sci files are ignored later
[08:01] <tsdgeos> or i can do
[08:01] <tsdgeos> licensecheck tests/unittests/plugins/Utils/modeltest.cpp
[08:01] <tsdgeos> and that's it :D
[08:01] <tsdgeos> i just added a few files
[08:02] <dandrader> mzanetti, hi. have you had time to check this autopilot issue I e-mailed you about?
[08:03] <mzanetti> dandrader: I've seen the mail, but still working on the mail queue. I know the solution to your issue and will come back to you within the next half hour
[08:03] <mzanetti> well... maybe not directly the solution. but can definitely help you
[08:04] <dandrader> mzanetti, awesome! thanks!
[08:07] <Saviq> dandrader, DUDE! don't you sleep!?
[08:07] <Saviq> 5am!? really?
[08:10] <dandrader> Saviq, yeah. woke up early so that I can go climbing in the afternoon :)
[08:11] <Saviq> dandrader, nice
[08:11] <Saviq> dandrader, but then...
[08:11] <Saviq> 5am!? really?
[08:11] <Saviq> ;)
[08:11] <mzanetti> Saviq: I keep on wondering too
[08:11] <mzanetti> :)
[08:11] <dandrader> actually, I started at 04:30 :)
[08:11] <mzanetti> dandrader: I'd have time for you now
[08:12] <mzanetti> lets not flood the channel...
[08:16] <tsdgeos> Saviq: http://bazaar.launchpad.net/~aacid/unity/sortfilterproxymodelqml_split/revision/611 and http://bazaar.launchpad.net/~aacid/unity/sortfilterproxymodelqml_split/revision/612
[08:17] <Saviq> tsdgeos, yup, looks good
[08:21] <tsdgeos> he
[08:21] <tsdgeos> Found 2 license prolems:
[08:21] <tsdgeos> tests/unittests/plugins/Utils/modeltest.h	LGPL (v2.1)	2013 Digia Plc and/or its subsidiary(-ies)
[08:21] <tsdgeos> tests/unittests/plugins/Utils/modeltest.cpp	LGPL (v2.1)	2013 Digia Plc and/or its subsidiary(-ies)
[08:22] <tsdgeos> Houston, we have a prolem
[08:23] <tsdgeos> Saviq: shall i simply remove the code and be happy with worse testing?
[08:23] <Saviq> tsdgeos, so it seems licensecheck checks for Canonical copyright explicitly?
[08:23] <tsdgeos> not on my machine
[08:24] <tsdgeos> but maybe on whatever that is runninng
[08:24] <Saviq> tsdgeos, yeah, it's set up so on jenkins, probably
[08:24] <Saviq> mzanetti, can you shed some light ^?
[08:24]  * mzanetti reads backlog
[08:24] <mzanetti> hehe
[08:24]  * mzanetti adds Digia to the list of allowed licenses
[08:25] <Saviq> tsdgeos, see :)
[08:28] <mzanetti> Saviq: tsdgeos: https://code.launchpad.net/~mzanetti/pbuilderjenkins/add-digia-license/+merge/159319
[08:41] <Saviq> reboot
[08:42] <tsdgeos> uhoh
[08:42] <tsdgeos> my kernel is oopsing
[08:42] <tsdgeos> in audio related stuff
[08:42] <tsdgeos> did my HW just break?¿
[08:45] <didrocks> sil2100: hey, what's the news on the street? on what are you working on? :)
[08:45] <didrocks> sil2100: I'm afraid we won't be able to test your branch though, the power up/down machine is broken in the data center
[08:45] <didrocks> sil2100: so we can't run autopilot…
[08:49] <sil2100> didrocks: hi! I have been continuuing some testing regarding HUD unit tests reliability and checking on merges and their failures
[08:49] <sil2100> didrocks: which branch do you have in mind?
[08:49] <sil2100> The one with AP fixes for raring?
[08:49] <sil2100> (armhf seems failing there for unknown reasons for me...)
[08:49] <didrocks> sil2100: this one, but in paticular all the "add all the packages for autopilot to run"
[08:50] <didrocks> sil2100: great! Keep hacking on the HUD, would be great to have something passing today ;)
[08:51] <sil2100> I also hope https://code.launchpad.net/~robru/camera-app/packaging/+merge/153651 will get in pretty soon!
[08:53] <didrocks> sil2100: yeah, did you see the questions? if you have more QML knowledge than I…
[08:53] <sil2100> didrocks: btw. do you know the status of https://code.launchpad.net/~mterry/qtvideo-node/arches/+merge/158405 ? Since I remember it was blocked because of some issues with quantal...
[08:53] <sil2100> On which fginther was working I think?
[08:53] <didrocks> sil2100: right, I don't know where fginther is with this
[08:53] <didrocks> sil2100: if you don't mind tracking it :)
[08:54] <sil2100> Ok, will do that then - since I saw a discussion yesterday as well about it but didn't see if it got resolved ;)
[08:55] <didrocks> sil2100: excellent, thanks!
[08:58] <smspillaz> didrocks: just got some foundations laid so that we can do acceptance tests on compiz plugins
[08:58] <smspillaz> which is awesome
[08:59] <didrocks> smspillaz: oh! excellent news :) acceptance tests needs a UI though?
[08:59] <smspillaz> didrocks: xorg-gtest
[09:00] <smspillaz> https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1101026/+merge/159307 that should allow us to run move, resize, grid, decor without opengl
[09:00] <smspillaz> so we can run them as a CI job
[09:00] <didrocks> smspillaz: ah, even better :)
[09:00] <smspillaz> yep, been hoping to have that for a while
[09:01] <didrocks> smspillaz: this should be even some autopkgtests :)
[09:01] <didrocks> for debian and ubuntu
[09:01] <smspillaz> I just need to see how broken things are when running those plugins without opengl, as it hasn't worked in over a year
[09:01] <didrocks> smspillaz: yeah ;)
[09:01] <tsdgeos> and the oops went away
[09:01] <tsdgeos> now i don't know if the HW is half dead or the SW is half broken :-/
[09:01] <smspillaz> didrocks: well, it should work as an autopkgtest as long as it works in CI. iirc xorg-gtest was in main now
[09:02] <didrocks> smspillaz: autopkgtests are running against the installed version of your software
[09:02] <didrocks> smspillaz: so it needs tweaking to support that :)
[09:02] <didrocks> smspillaz: those are triggered when a reverse dependency is uploaded for instance
[09:02] <smspillaz> didrocks: ah I see. I think that probably makes more sense for autopilot then
[09:03] <smspillaz> hmm
[09:03] <didrocks> smspillaz: it's different from autopilot, but I agree the lines are not quite clear
[09:03] <smspillaz> yeah I can see the difference, I'm just wondering what the implementation would look like
[09:04] <didrocks> yeah, quite hard to decipher some guidances
[09:04] <smspillaz> yould probably do it, you'd just need to "install" the test binaries or something
[09:04] <smspillaz> *you could probably
[09:05] <MacSlow> smspillaz, hey Sam!
[09:05] <smspillaz> howdy
[09:06] <smspillaz> MacSlow: how goes things?
[09:06] <MacSlow> smspillaz, very busy :)
[09:06] <smspillaz> I can imagine ;-)
[09:16] <tsdgeos> mzanetti: i guess it'll take a while until that Digia fix gets to the jenkins slaves?
[09:16] <mzanetti> tsdgeos: I have to apt-update and install it on all nodes manually :/
[09:16] <tsdgeos> really?¿
[09:16] <tsdgeos> ouch
[09:17] <mzanetti> yeah...
[09:17] <mzanetti> I think there was an approach to use landscape for the jenkins nodes. not sure why thats not the case any more
[09:18] <mzanetti> tsdgeos: well... there might be a cron job that updates the pbuilderjenkins package nightly... but that won't happen before tomorrow
[09:18] <tsdgeos> he he
[09:19] <mzanetti> tsdgeos: is your MP prone to conflicts and should be merged asap or can it wait until it gets deployed somehow (i.e. someone else has a high prio fix and needs to update stuff)
[09:19] <tsdgeos> mzanetti: i guess it can wait
[09:20] <sil2100> didrocks: anything else I can help with in-between test runs?
[09:20] <mzanetti> tsdgeos: ok... in case it kepps on failing after a reasonable amount of time, ping me and I'll update
[09:20] <didrocks> sil2100: plenty of things! :) one sec
[09:21] <sil2100> :)
[09:29] <didrocks> sil2100: do you want to do a hangout?
[09:29] <didrocks> (a quick one)
[09:32] <sil2100> Oh boy... didn't migrate to chromium yet! Is screensharing needed ;)? If it's not crucial, I could
[09:32] <didrocks> sil2100: no screensharing I guess
[09:32] <sil2100> didrocks: ok, ready when you are then
[09:33] <didrocks> sil2100: https://plus.google.com/hangouts/_/3a7c0c16c2cce6a379d806887326c30f5e5388ac?authuser=0&hl=it
[09:36] <mzanetti> tsdgeos: could you just build and run this one please and let me know if its able to load the dashes? https://code.launchpad.net/~mterry/unity/phablet-greeter-lightdm/+merge/158245
[09:36] <mzanetti> tsdgeos: it does not here... but I can't spot the difference to trunk - which works here
[09:38] <tsdgeos> mzanetti: device or pc?
[09:38] <mzanetti> pc
[09:39] <tsdgeos> doing
[09:43] <tsdgeos> mzanetti: seems to work here
[09:43] <tsdgeos> what problem are you having exacly?
[09:44] <mzanetti> tsdgeos: any hints what could be wrong here?
[09:44] <mzanetti> tsdgeos: ./run'ing trunk works fine here, but on this one it just doesn't load any dash
[09:44] <mzanetti> tsdgeos: I already deleted builddir and built again
[09:45] <tsdgeos> mzanetti: so you get a totally empty thing after opening the greeter?
[09:46] <mzanetti> tsdgeos: yes
[09:46] <tsdgeos> mzanetti: well, to be honest i'm not really running that branch alone, i got trunk and merged that branch in, maybe that makes a difference?
[09:46]  * tsdgeos tries the pristine branch
[09:46] <mzanetti> tsdgeos: I tried that too... says nothing to merge
[09:47] <mzanetti> I tried the other way round tho... cloned that branch and merged trunk into it
[09:49] <Saviq> mzanetti, I tried the set_target_properties()
[09:49] <Saviq> mzanetti, that doesn't get populated to the dependant targets
[09:50] <Saviq> mzanetti, and I agree on the cmake module, thought of that myself, and will do
[09:50] <mzanetti> Saviq: oh... that sucks... but afaics we would only need it on the real ctest ones...
[09:50] <mzanetti> Saviq: because the others are verbose themselves... while only make check uses ctest and hides output
[09:50] <Saviq> mzanetti, we would need to set it up on each add_test() manually :/
[09:50] <mzanetti> ok... skip it then...
[09:51] <Saviq> mzanetti, I have creating a dummy Makefile in our root on my TODO
[09:51] <Saviq> mzanetti, that will forward whatever to builddir
[09:51] <mzanetti> uuhhh! nice one!
[09:51] <Saviq> mzanetti, and we can then put the env there
[09:52] <mzanetti> +1
[09:52] <Saviq> ok, so .cmake is remaining
[09:54] <tsdgeos> mzanetti: ran it on the device, works fine too
[09:54] <tsdgeos> mzanetti: honestly no idea how to debug it :-/
[09:56] <mzanetti> tsdgeos: ok... thanks...
[09:56] <Saviq> can I help?
[09:56] <tsdgeos> mzanetti: other than adding a million printfs of course :D
[09:56] <mzanetti> Saviq: https://code.launchpad.net/~mterry/unity/phablet-greeter-lightdm/+merge/158245
[09:57] <mzanetti> Saviq: running this on my PC does not load any lenses
[09:57] <mzanetti> Saviq: running trunk on my PC works fine
[09:57] <mzanetti> Saviq: says nothing to be merged
[09:58] <Saviq> mzanetti, checking
[09:58] <mzanetti> Saviq: well, it works on tsdgeos's machine... so probably something locally here... I would still like to understand whats happening
[09:58] <mzanetti> but not really sure how to approach
[09:59] <tsdgeos> mzanetti: which sdk do you have?
[09:59] <mzanetti> tsdgeos: sdk?
[09:59] <Saviq> mzanetti, tried ./build_unity -c? I wonder if it's related to your having libunity installed
[09:59] <tsdgeos>  qtdeclarative5-ubuntu-ui-toolkit-plugin
[09:59] <tsdgeos> 0.1.42~raring1 ?
[09:59] <tsdgeos> mzanetti: ↑↑
[10:00] <mzanetti> tsdgeos: same here
[10:00] <mzanetti> Saviq: no, didn't try
[10:00] <mzanetti> Saviq: still wouldn't explain trunk working, would it? (as the MP doesn't seem to change that part)
[10:00] <tsdgeos> mzanetti: ok
[10:00] <Saviq> mzanetti, true
[10:01] <Saviq> mzanetti, works here
[10:01] <Saviq> mzanetti, any interesting output on the console?
[10:02] <mzanetti> Saviq: nope. exactly the same except warnings caused by lenses are missing
[10:05] <Saviq> mzanetti, no idea here
[10:05] <Saviq> mzanetti, I'd go for a rm -R ../unity_build
[10:05] <Saviq> and start over
[10:05] <tsdgeos> may it be related to you not having "some other lightdm" thing installed?
[10:05]  * Saviq doesn't like the .h links, though
[10:06] <tsdgeos> mzanetti: just in case this is what i have http://paste.kde.org/~tsdgeos/726320/
[10:06] <mzanetti> tsdgeos: the lightdm part is the only thing working :D
[10:06] <mzanetti> anyways, thanks
[10:07] <tsdgeos> i know, but won't hurt to install a few packages :D
[10:19] <Cimi> Saviq, saw your ping this morning but I'm with some headache cause I had insomnia last night and slept only a few, was for your cmake refactor? looks good to me
[10:19] <Cimi> (I took an aspirin btw)
[10:19] <Saviq> Cimi, no, it was about yesterday's talk about dee in the mock plugin
[10:20] <Cimi> Saviq, ok tell me
[10:20] <Saviq> Cimi, there can be no dee in there, you just need a ListMOdel
[10:20] <Saviq> Cimi, so you need to create/use something that's based on QAbstractListModel
[10:20] <Cimi> Saviq, but it's categories from the c++ plugin?
[10:20] <Cimi> ah ok
[10:20] <Saviq> Cimi, it doesn't care about dee
[10:20] <Cimi> ok
[10:20] <Saviq> Cimi, it's an implementation detail the tests can't know about
[10:25] <mzanetti> Cimi: you need DeeVariantText in a test?
[10:25] <Cimi> mzanetti, I need a list modelk
[10:25] <Cimi> mzanetti, lens.categories
[10:26] <mzanetti> Cimi: ah... so why not use ListModel (I didn't get the full conversation so I might tell you outdated stuff now - just tell me to shut up in that case)
[10:27] <Cimi> mzanetti, for me everything is ok, I have almost 0 experience in c++/qt, I have seen the real plugin was returning a dee model
[10:27] <Cimi> mzanetti, and thought it was required the same
[10:27] <Cimi> also I need to see how to write a model in c++
[10:28] <mzanetti> Cimi: not sure if it helps you... but here I mocked some parts of Dee in the most simplistic way there is: https://code.launchpad.net/~mzanetti/unity/phablet-test-filtergrids/+merge/158941
[10:30] <Saviq> mzanetti, uh, add_custom_target(check DEPENDS test) doesn't work...
[10:30] <Saviq> freakin' test isn't a normal target
[10:30] <Saviq> at least not under make (it worked under ninja...
[10:31] <mzanetti> hmpf...
[10:33] <Saviq> but I did try to debuild it...
[10:33]  * Saviq tries again
[10:35] <Saviq> hmm it works
[10:36]  * Saviq doesn't get it
[10:38] <Saviq> mzanetti, why the --force-yes?
[10:44] <mzanetti> Saviq: already delete the branch again
[10:44] <mzanetti> Saviq: it kept on failing here... but while editing the comment in the MP I flashed todays image and it worked again
[10:45] <Saviq> mzanetti, k
[10:45] <Saviq> mzanetti, seem dh_auto_test actually uses the test target (at least for CMake projects)
[10:46] <Saviq> mzanetti, so the custom target wasn't helping anyway
[10:46] <Saviq> and the failures were silent anyway
[10:47] <Saviq> and!
[10:47] <Saviq> it sets CTEST_OUTPUT_ON_FAILURE by itself
[10:48] <Saviq> so we can get rid of the check target altogether
[10:49] <Saviq> yup
[10:50] <mzanetti> Saviq: yeah... the check target was just to keep syntax compatible to googletest, right?
[10:50] <mzanetti> I haven't seen that before either....
[10:50] <Saviq> mzanetti, I thought it was about debhelper...
[10:50] <Saviq> didrocks, question - why the "check" target?
[10:50] <mzanetti> but jenkins executes "make check || make test" anyways... so fine with me
[10:51] <didrocks> Saviq: sorry, out of context, what check target? :)
[10:51] <didrocks> Saviq: jenkins merger?
[10:51] <Saviq> didrocks, no, in general
[10:51] <Saviq> didrocks, we had a custom "check" target in CMake
[10:51] <Saviq> for compatibility with...
[10:51] <Saviq> something
[10:51] <Saviq> I thought it was about dh
[10:52] <tsdgeos> Saviq: so in the dash search we still have that occasional crash on search
[10:52] <didrocks> Saviq: dh runs make check, it's a general target we have in projects to run unit tests and tests that can be run with isolation
[10:52] <Saviq> didrocks, actually dh runs make test
[10:52] <tsdgeos> i've checked and going to carousel+listview+patches still crashes
[10:52] <Saviq> didrocks, at least under CMake
[10:52] <tsdgeos> so it's unrelated
[10:52] <tsdgeos> not sure if carousel at all or not
[10:52] <didrocks> Saviq: right, it depends on the build tool
[10:52] <Saviq> tsdgeos, uhm, was hoping it is
[10:52] <tsdgeos> nah
[10:52] <tsdgeos> the bt is weeeeird
[10:53] <didrocks> Saviq: autotools are more "make check": http://www.sourceware.org/autobook/autobook/autobook_98.html
[10:53] <Saviq> didrocks, yeah exactly, so I was wondering if there's any reason to keep the check target if we have issues with keeping it :)
[10:53] <tsdgeos> http://paste.kde.org/~tsdgeos/726350/
[10:53] <tsdgeos> QQuickWindowIncubationController::incubate
[10:53] <Saviq> tsdgeos, that I never saw...
[10:53] <tsdgeos> what's a incubation controller? :D
[10:53] <didrocks> Saviq: if you have a make test, that's fine, use that one :)
[10:53] <Saviq> didrocks, \o/
[10:53] <tsdgeos> Saviq: ah because you where not running with your own Qt so you didn't see the assert but the crash probably
[10:53] <tsdgeos> which may have been a bit different
[10:54] <didrocks> Saviq: let me just recheck that dh_tests is indeed running that one as well for cmake
[10:54] <Saviq> didrocks, sbuild didn't complain
[10:54] <Saviq> tsdgeos, yeah, probably
[10:54] <tsdgeos> when running with the system qt i get http://paste.kde.org/~tsdgeos/726356/
[10:54] <tsdgeos> Saviq: ↑
[10:54] <didrocks> Saviq: didn't complain != run :p
[10:54] <Saviq> didrocks, it did run the tests, yes
[10:55] <didrocks> Saviq: but yeah, dh_auto_test is running make test and make check, depending on what it found in the makefile
[10:55] <Saviq> didrocks, ah, smarts!
[10:55] <Saviq> didrocks, awesome, thanks
[10:55] <didrocks> Saviq: yw ;)
[10:55] <Saviq> tsdgeos, not even, I think
[10:55] <tsdgeos> ok
[10:55] <Saviq> tsdgeos, so it might actually be related (i.e. you fixed one thing, but there's another happening anyway)
[10:56] <tsdgeos> yeah
[10:56] <tsdgeos> this one gonna be harder i think
[10:56] <Saviq> mzanetti, will you tell me I should split out the cmake stuff out of that MP? (/me cries away for git)
[10:57] <mzanetti> Saviq: huh?
[10:57] <mzanetti> Saviq: from the flatten-qmltests one?
[10:57] <Saviq> mzanetti, yes
[10:57] <mzanetti> why that?
[10:57] <Saviq> mzanetti, 'cause it's not really related ;)
[10:57] <mzanetti> no... just merge it as is... history isn't worth a thing with bzr anyways
[10:58] <Saviq> indeed
[10:58] <Saviq> mzanetti, what targets to we want "forwarded" to builddir?
[10:58] <mzanetti> alltests
[10:58] <mzanetti> autopilot
[10:58] <mzanetti> hmm.... thats the ones I use the most
[11:00] <mzanetti> Saviq: can you please check lines 1244 and 1257 in here https://code.launchpad.net/~mterry/unity/phablet-greeter-lightdm/+merge/158245
[11:00] <mzanetti> Saviq: I think there is something fishy - we should not need this
[11:00] <Saviq> mzanetti, indeed
[11:01] <mzanetti> besides the mock should probably live somewhere in tests/ not plugins/
[11:01] <Saviq> mzanetti, I'm thinking the plugin links to the mocks
[11:01] <Saviq> mzanetti, which are separate .so
[11:01] <Saviq> which would, of course, be bad
[11:01] <mzanetti> yeah... I guess so...
[11:03] <Saviq> mzanetti, is there a MP from you fixing the path/LD in autopilot?
[11:03] <mzanetti> Saviq: no...... only the builddir thingie...
[11:04] <mzanetti> Saviq: but I can do
[11:04] <Saviq> mzanetti, could there be?
[11:04] <mzanetti> yea
[11:04] <Saviq> mzanetti, yes please
[11:04] <Saviq> mzanetti, not sure about fixing it _in_ the .py, too
[11:04] <mzanetti> Saviq: where else?
[11:04] <Saviq> mzanetti, it's only relevant for local builds
[11:05] <mzanetti> yeah... the py distinguishes between local and installed builds
[11:05] <Saviq> mzanetti, ok, more local
[11:05] <Saviq> mzanetti, as in: if you have the deps installed
[11:05] <Saviq> mzanetti, the LD isn't required
[11:05] <Saviq> even though you build locally
[11:05] <mzanetti> my case, that is
[11:05] <Saviq> yes ;)
[11:06] <Saviq> so I wonder if the Makefile I'm writing now could have bearing here
[11:09] <Saviq> mzanetti, with http://pastebin.ubuntu.com/5715632/
[11:09] <Saviq> mzanetti, make autopilot works here
[11:10]  * Saviq needs to learn Ninja to do the same for it
[11:11] <mzanetti> Saviq: what if you execute "make autopilot" within the build dir?
[11:11] <Saviq> mzanetti, it won't
[11:11] <Saviq> of course
[11:11] <Saviq> mzanetti, but if you go ./qml-phone-shell in the build dir
[11:11] <Saviq> mzanetti, it will fail just as well
[11:12] <dandrader> mzanetti, is there any way to known if ci is building (or is scheduled to build) my merge proposal?
[11:12] <Saviq> mzanetti, but it's temporary
[11:12]  * dandrader is anxious
[11:12] <Saviq> dandrader, http://s-jenkins:8080/job/unity-phablet-ci/
[11:13] <Saviq> dandrader, you need to look through the running jobs
[11:13] <Saviq> dandrader, and look at their parameters
[11:13] <Saviq> there's a link on the left
[11:13] <Saviq> dandrader, http://s-jenkins:8080/job/unity-phablet-ci/583/parameters/?
[11:13] <mzanetti> dandrader: yeah... open parameters and then just use the "Previous build"/"Next build" links
[11:14] <dandrader> mzanetti, Saviq  excellent! thanks!
[11:15] <dandrader> jesus.. it takes time "Started 42 min ago"
[11:15] <mzanetti> Saviq: I'm fine with it... if you're fine with it we're good I'd say
[11:15] <Saviq> dandrader, it's most probably queued
[11:16] <mzanetti> dandrader: hmm... let me check what's blocking the queue
[11:16] <Saviq> dandrader, http://10.97.2.10:8080/job/unity-phablet-qmluitests/
[11:16] <Saviq> mzanetti, http://10.97.2.10:8080/job/unity-phablet-qmluitests/376/console hangs
[11:19] <Saviq> mzanetti, we shouldn't need to do anything in run_on_device - build-dep are handling it (we need a release for that, though)
[11:20] <Saviq> mzanetti, beat me to it
[11:20] <dandrader> damn whitespace...
[11:21] <Saviq> dandrader, http://vim.wikia.com/wiki/Highlight_unwanted_spaces ;)
[11:21] <Saviq> dandrader, also, MAKE TEST! ;P
[11:23] <dandrader> I have a "set listchars" for that but it doesn't seem to be working so well
[11:30] <Saviq> mzanetti, pushed the Makefile
[11:30] <mzanetti> Saviq: pushed to where?
[11:30] <Saviq> mzanetti, same branch
[11:31] <mzanetti> Saviq: you sure?
[11:31] <Saviq> no
[11:31] <Saviq> mzanetti, now
[11:34] <Saviq> mzanetti, it's quite stupid, but saves the "-C builddir"
[11:35] <Saviq> and remembering it, too
[11:35] <mzanetti> I like it a lot
[11:35] <mzanetti> just for doing quick reviews the builddir thingie was quite annoying me
[11:36] <mzanetti> Saviq: approved
[11:41] <Saviq> mzanetti, cheers
[11:44] <Saviq> mzanetti, tsdgeos, what did we agree upon yesterday about the utils vs. mocks in /tests/ (and the tests for them)
[11:44] <Saviq> /tests/{utils,mocks} for the actual plugins
[11:44] <Saviq> and the tests for them? ;)
[11:44] <mzanetti> Saviq: yeah... regarding tests for utils we didn't come to a clear conclusion
[11:45] <mzanetti> Saviq: if you promise to keep them at one level you can put them to /tests/utils/tests :D
[11:45] <Saviq> lol
[11:48] <mzanetti> anyone? https://code.launchpad.net/~mzanetti/unity/phablet-test-filtergrids/+merge/158941
[11:48] <mzanetti> Cimi would like to get a second opinion before top-approving
[11:52] <tsdgeos> :D
[11:52] <tsdgeos> what mzanetti said
[11:52] <tsdgeos> lunch!
[12:01] <mzanetti> Saviq: do'h!
[12:01] <mzanetti> Saviq: Jenkins searches for a Makefile before it searches for a CMakeLists.txt
[12:01] <Saviq> mzanetti, jenkins or dh?
[12:02] <mzanetti> Saviq: probably both
[12:02] <Saviq> yeah, dh
[12:02] <Saviq> damn
[12:02] <Saviq> let's drop it for now
[12:02] <Saviq> I have an idea for later
[12:03] <Saviq> will probably go for a Makefile.in in ${CMAKE_SOURCE_DIR}
[12:03] <Saviq> mzanetti, pushed
[12:10] <smspillaz> Trevinho: andyrock: got a question about the switcher if either of you are around
[12:11] <smspillaz> Trevinho: andyrock: do either of you know if the intended design for the switcher was that alt-tab (quickly) was supposed to take you to the next *application* or the next *window* (of the same application)
[12:11] <Saviq> mzanetti, what do you make of these failures https://jenkins.qa.ubuntu.com/job/unity-phablet-quantal-armhf-ci/585/console ?
[12:11] <smspillaz> there's an AP test that suggests its the former, although looking at SwitcherModel it doesn't even try to do that
[12:12] <Saviq> smspillaz, AFAIK, alt+tab -> applications, alt+${key_over_tab} -> windows of the same application
[12:12] <mzanetti> Saviq: missing merge with trunk: line 1875 of https://code.launchpad.net/~dandrader/unity/phablet_remove_fakes_from_qml/+merge/158370
[12:12] <smspillaz> that's what I thought too
[12:13] <mzanetti> Saviq: not really a merge, but that file has been moved to Components
[12:13] <Saviq> mzanetti, k
[12:15] <Saviq> dandrader, you need to merge trunk again in your fakes branch
[12:15] <dandrader> Saviq, fixing it now
[12:16] <dandrader> done. let's see what happens next
[12:16] <Saviq> lol
[12:19] <mzanetti> dandrader: just merging is not enough... the file has been moved to Components. you need to adjust your .install file too
[12:21] <mzanetti> dandrader: just remove line 1875 from your diff
[12:21] <dandrader> mzanetti, I did that
[12:21] <mzanetti> ok
[12:25] <sil2100> fginther: ping! Give me a sign once you're online :)
[12:31] <sil2100> didrocks: can you access the Touch Apps docs?
[12:31] <sil2100> Since I get weird errors...
[12:32] <didrocks> sil2100: do you have a link handy?
[12:32] <didrocks> as we are having a lot of docs :)
[12:35] <mterry> didrocks, did you deploy the manual upload or shall I?
[12:35] <mterry> the manual mode for Raring I meant
[12:35] <didrocks> mterry: no, I can do it, it would mean that for today and tomorrow, we need to manually publish though
[12:39] <sil2100> https://code.launchpad.net/~sil2100/qtubuntu-camera/add_bootstrapping/+merge/159372 <- if anything
[12:40] <sil2100> (wrong channel)
[12:40] <mterry> didrocks, fair, if we don't like that, it can wait easy enough
[12:41] <didrocks> mterry: yeah, let's pull on Thursday?
[12:41] <didrocks> mterry: but at least, everything is prepared :)
[12:41] <didrocks> mterry: thanks btw!
[12:52] <smspillaz> didrocks: so the good news is that none of the WM related tests appear to be failing using lp:compiz
[12:52] <mzanetti> I guess its not possible to run old Unity windowed, is it?
[12:52] <smspillaz> mzanetti: it is, dunno how tested it is
[12:52] <didrocks> smspillaz: \o/ excellent work, that's a first good step to trust the WM behavior :)
[12:53] <smspillaz> mzanetti: unity-standalone
[12:53] <mzanetti> cool, thanks
[12:59] <mzanetti> unity : Depends: libnux-abiversion-20121121.01
[12:59] <mzanetti> which is a virtual package provided by libnux-4.0-0 which is already installed
[13:00] <mzanetti> still it doesn't let me to install unity
[13:00] <paulliu> Hi, I'm writing tests for DashPeople.qml. But still don't get how the data is passed from lens daemon to qml?
[13:00] <mzanetti> paulliu: let me check
[13:01] <mzanetti> paulliu: do you have a specific line of code you don't understand?
[13:01] <paulliu> For example, Binding { target: lensView.lens... ,  who assigned the lensView.lens?
[13:02] <tsdgeos> what do you mean assigned?
[13:02] <tsdgeos> lensView is an object and lens is a property of the object, no?
[13:03] <paulliu> lensView is the root element of DashPeople.qml
[13:03] <paulliu> But it seems to me that it is inherit by LensView Object.
[13:03] <paulliu> inherit from.
[13:04] <paulliu> I'm thinking provide some mock-up data in tests and do some UI tests there? So I'd like to fake the data from lens?
[13:05] <tsdgeos> well DashPeople is a LensView
[13:06] <mterry> didrocks, who was I supposed to ping with UTAH errors?
[13:07] <mzanetti> paulliu: yeah... DashPeople inherits from LensView, which means it inherits the property "lens"
[13:08] <paulliu> mzanetti: ok, but that property is undefined when I create a instance of DashPeople.
[13:08] <paulliu> mzanetti: Am I doing something wrong?
[13:08] <fginther> sil2100, pong chirp pong
[13:09] <tsdgeos> paulliu: of course it's undefined
[13:09] <tsdgeos>     property Lens lens
[13:09] <tsdgeos> nothing is assigned
[13:09] <tsdgeos> so it's undefined
[13:09] <tsdgeos> it does exist with no value
[13:09] <mzanetti> paulliu: in Dash/Dash.qml
[13:10] <mzanetti> paulliu: there is a Model holding all Lenses and assigning the appropriate LensViews as delegates
[13:10] <paulliu> mzanetti: ah..ok. Let me check.
[13:10] <mzanetti> paulliu: sorry... DashContent.qml
[13:11] <mzanetti> paulliu: line 124
[13:11] <paulliu> mzanetti: yeah.
[13:11] <paulliu> mzanetti: ok. thanks.
[13:12] <mzanetti> paulliu: so you can just create your own "Lens" and assign it to DashPeople in your test
[13:12] <tsdgeos> dednick: the list deletes the delegates as its own discretion
[13:13] <paulliu> mzanetti: Yeah, I'll do it.
[13:13] <tsdgeos> dednick: are we having problems when that happens?
[13:14] <didrocks> mterry: the CDU is dead
[13:14] <mterry> didrocks, CDU?
[13:14] <didrocks> mterry: the hw rebooting the machines
[13:14] <didrocks> that's why everything is broken
[13:14] <mterry> didrocks, boo
[13:14] <didrocks> I just pinged you on the qa channel :)
[13:19] <kgunn> mzanetti: mterry oops....moving here
[13:20] <mzanetti> so... anyone has a hint why I can't install unity? http://paste.ubuntu.com/5715900/
[13:20] <mzanetti> kgunn: yeah... same here... wanted to read through the launcher docs
[13:21] <mzanetti> kgunn: anyways, mterry asks who will implement the Pinentry thingies
[13:21] <tsdgeos> libnux-4.0-0 4.0.0phablet14bzr763raring0
[13:21] <tsdgeos> brrrr
[13:21] <tsdgeos> mzanetti: phablet-age stuff?
[13:21] <tsdgeos> do you have the phone-ppa (the unsafe one) enabled?
[13:22] <mzanetti> tsdgeos: yeah... but all the unity packages are not from there... and I would understand if it crashes because of the ABI breakage...
[13:23] <kgunn> mzanetti: mterry do either of you have a sense for size? e.g. days vs weeks vs month?.....what little i've witnessed so far would seem like ~1week
[13:24] <kgunn> mzanetti: are you wanting to do it? :)
[13:25] <kgunn> mterry: to answer your original question...not assigned at the moment....and we need to capture
[13:25] <kgunn> mterry: in a bp
[13:25] <mzanetti> kgunn: yeah, sure... I'm just not exactly sure on the rest of the schedule and what exactly it includes
[13:25] <tsdgeos> tsdgeos: disable that ppa, otherwise the versions conflict between eachothers and everyone is unhappy
[13:26] <tsdgeos> err
[13:26] <kgunn> mzanetti: right...when gdocs are back, take a look at monthly first, see the launcher load...then let's chat
[13:26] <tsdgeos> mzanetti: ↑↑↑
[13:26] <tsdgeos> that ppa is not for desktop usage
[13:26] <mterry> kgunn, mzanetti, yeah, I'm in the middle of trying to figure out bp and stuff
[13:27] <kgunn> mterry: should we just glom on to this one ? https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-greeter
[13:27] <kgunn> mterry: or create a new one just for pin-entry
[13:28] <mzanetti> kgunn: mterry: So in general yes, I'd be happy to help out with this if the schedule permits it - which we will find out once the requirements are captured
[13:29] <kgunn> mzanetti: mterry surely for 13.10 we can limit it to pin....leaving osk/passphrase for after
[13:30] <mzanetti> wouldn't entering a pin also require an OSK?
[13:30] <mzanetti> (depends on the design I guess)
[13:30] <kgunn> mzanetti: true...10 key most likely
[13:31] <kgunn> mzanetti: i was just trying to limit the ui effort to one layout vs doing 2 before 13.10
[13:31] <mzanetti> kgunn: yeah... a matter of the layout, but still, the OSK needs to be there (unless they want us to implement something more fancy for just numbers ourselves)
[13:32] <kgunn> mzanetti: its basically the phone dial pad widget
[13:32] <kgunn> 10 key that is
[13:32] <mzanetti> I see
[13:32] <dednick> tsdgeos: yes.
[13:33] <tsdgeos> dednick: ok, that's bd, let's do the standup and talk about it later again
[13:33] <sil2100> fginther: chirp ;)
[13:33] <sil2100> fginther: could you tell me what's the status with https://code.launchpad.net/~mterry/qtvideo-node/arches/+merge/158405 ? Since I remember the issue was the lack of stack for quantal or something?
[13:37] <tsdgeos> dandrader: try if this helps https://code.launchpad.net/~nick-dedekind/unity/phablet-tests-menucontent/+merge/158562 (i think it's the "this" part for the Lens constructor)
[13:39] <fginther> sil2100, I'm not sure how we solve the quantal dependency problem at the moment. We almost have changes in place to use the daily build ppa, but that won't help here
[13:43] <mterry> fginther, sil2100: it will help; we just need to have the PPA used by CI, rebuild the PPA, then retrigger that merge job's CI
[13:43] <Saviq> hrm
[13:44] <fginther> mterry, sil2100 I'll get it setup
[13:44] <mterry> didrocks, we will have the daily-release jobs building for quantal too, right?
[13:46] <didrocks> mterry: no, there is no gain of daily releasing touch for quantal
[13:46] <didrocks> knowing it will be dropped soon
[13:46] <sil2100> fginther: thanks!
[13:47] <mterry> didrocks, :(  well, then we won't be able to CI a lot of these things.  Like, packages depend on platform-api for example.  If we don't daily-release platform-api...
[13:47] <sil2100> Well, we need the quantal packages fetched in CI at least as a 'dummy' workaround
[13:47] <sil2100> For quantal
[13:47] <didrocks> mterry: they still have a dput job in quantal, right?
[13:47] <didrocks> mterry: in a ppa
[13:47] <didrocks> without daily release
[13:48] <sil2100> We can push manually to the daily-next PPA when there's need, right?
[13:48] <didrocks> mterry: then, I guess sergiusens will remove quantal support in the follow days when, he's happy with his raring image?
[13:48] <sil2100> As long as CI would use the daily-next PPA in CI
[13:48] <sil2100> Damn
[13:48] <sil2100> -CI
[13:48] <didrocks> sil2100: ah, yeah, we can have a manual push, but TBH, I think it's not a priority and CI should continue commit putting to a ppa for quantal?
[13:49] <fginther> didrocks, that's what I thought we would be doing
[13:49] <kgunn> nic-doffay: http://qt-project.org/doc/qt-5.0/qtquick/scenegraph-openglunderqml.html
[13:49] <mterry> didrocks, fginther: so CI will push to a PPA now?
[13:49] <mterry> I didn't know it did that
[13:49] <fginther> mterry, the upstream autolanding builds get dput into a ppa
[13:50] <mterry> fginther, fascinating.  I didn't realize we had two things pushing to PPAs (daily-release and CI)
[13:50] <didrocks> mterry: we are going to kill CI pushing to it once everything will be on the same page :)
[13:50] <mterry> fginther, that's why I was pushing for having the daily-release PPA included in CI jobs, because I thought it had to be to pick up previous builds
[13:51] <mterry> fginther, where will the CI quantal phablet builds go now?
[13:51] <fginther> mterry, so the ci jobs dput to ppa:phablet-team/ppa
[13:51] <didrocks> fginther: why you don't have a local repo?
[13:51] <didrocks> like for the rest
[13:51] <didrocks> makes more sense as you build debs
[13:53] <fginther> didrocks, I think the ppa was setup first and there was too much inertia to change
[13:54] <didrocks> fginther: weird, the local repo was something we supported even before you redo the jenkins stuff :)
[13:55] <sergiusens> didrocks: yup, lots of moving peices still, but its the plan
[13:56] <sil2100> Ok ok, so hm, what needs to be done still for the qtvideo-node merge to get in?
[13:57] <sil2100> ;)
[13:58] <fginther> sil2100, I'll build ci again when I get the job updated. It's possible the broken dependency has been updated
[13:58] <sergiusens> didrocks: local repo where? The PPA is later used to build from offspring
[13:58] <sergiusens> didrocks: which has intense firewall rules
[13:59] <sil2100> fginther: \o/ excellent!
[13:59] <sil2100> Thanks
[13:59] <didrocks> sergiusens: local repo so that CI always builds against latest
[13:59] <didrocks> sergiusens: separate upstream merger discussion :)
[14:00] <fginther> sergiusens, we use a local repo for building unity.  We essentially save the debs the jenkins builds
[14:00] <sergiusens> fginther: didrocks that's fine, but we need the debs somewhere, to build the actual image
[14:00] <sergiusens> so local repo doesn't cut it here
[14:01] <sergiusens> if it is just for a jenkins build to speed things up, no problem with that, but the packages would still need to be accessible outside
[14:01] <didrocks> sergiusens: right, forgot about that, but that won't be needed anymore once it daily releases
[14:01] <Saviq> nic-doffay, so, either you use a QML animation http://qt-project.org/doc/qt-5.0/qtquick/qtquick-qmltypereference.html#states-transitions-and-animations and use that in C++
[14:01] <sergiusens> didrocks: yup, exactly.. and once we build in cdimage, everything will need to be in the archive anyways....
[14:02] <Saviq> nic-doffay, or you could probably use QVariantAnimation http://qt-project.org/doc/qt-5.0/qtcore/qvariantanimation.html
[14:02] <didrocks> sergiusens: yep
[14:02] <Saviq> nic-doffay, but it's better to keep it in QML IMO
[14:02] <nic-doffay> Agreed Saviq it would simplify matters.
[14:02] <Saviq> nic-doffay, as it's not going to save us much to do it in C++, and will be less coupled to the actual behavior
[14:03] <Saviq> nic-doffay, so you will have a "mouseCoords" and "repelValue" from 0.0 to 1.0
[14:03] <Saviq> nic-doffay, bound to the MouseArea and Animation
[14:03] <Saviq> respectively
[14:03] <Saviq> nic-doffay, and those you will read in C++ and react accordingly
[14:15] <nic-doffay> Saviq, will get back to you now, just busy sorting something out...
[14:15] <Saviq> nic-doffay, k
[14:16] <nic-doffay> Saviq, I just ran qmlscene on the phone, it seems to have executed correctly with no issues.
[14:16] <nic-doffay> How can I check this on the actual phone? :P
[14:16] <nic-doffay> There's a gesture, I just can't seem to pick up which one it is.
[14:17] <nic-doffay> It's a bit erratic.
[14:24] <Saviq> nic-doffay, not sure what you mean :)
[14:24] <nic-doffay> There's a certain swipe gesture which brings up the qmlscene
[14:24] <nic-doffay> which is being run
[14:25] <nic-doffay> I just want to clarify what it is haha
[14:25] <nic-doffay> Because it's a bit erratic.
[14:25] <Saviq> nic-doffay, you just have to unlock the phone
[14:25] <Saviq> nic-doffay, by edge-swiping from the right
[14:25] <nic-doffay> Ok brilliant.
[14:25] <Saviq> nic-doffay, and then switch to the apps lens
[14:25] <Saviq> nic-doffay, to see the qmlscene entry in "Running apps"
[14:25] <Saviq> nic-doffay, and just tap on it to bring it to the front
[14:26] <Saviq> nic-doffay, also, if you just keep the phone unlocked, the app you run should come to the front by itself
[14:26] <kenvandine> smspillaz, when you have a moment, can you take a look at bug 1165343
[14:26] <kenvandine> smspillaz, it was introduced by rev 3636 of lp:compiz/0.9.9
[14:27] <kenvandine> smspillaz, it breaks all Qt apps that don't set position to other than 0,0
[14:28] <Cimi> Saviq, Categories is a list of CategoryFilters?
[14:28] <Saviq> Cimi, yes
[14:29] <Cimi> ok
[14:29] <Saviq> Cimi, actually
[14:29] <Saviq> Cimi, it's a ListModel
[14:29] <Saviq> Cimi, that exposes CategoryFilters as one of the roles
[14:29] <Cimi> Saviq, mmm
[14:29] <Saviq> Cimi, look in categories.{h,cpp}
[14:29] <Cimi> one thing at a time
[14:30] <Cimi> I am subclassinc qabstractlist
[14:30] <Cimi> one of the private variables is a qlist
[14:30] <Cimi>     QList<Type*> m_categories;
[14:30] <Cimi> so Type might be CategoryFilter here
[14:31] <Cimi> then I'll have to copy categoryfilter to the fake plugin too I think
[14:31] <Saviq> Cimi, but not the _actual_ CategoryFilter
[14:31] <Saviq> Cimi, just something that has the same API
[14:32] <Cimi> ok
[14:40] <nic-doffay> Question about the units quick.
[14:41] <nic-doffay> My qmlscene shows up pretty small on the desktop at 25 unit width and height, however it seems pretty large on the phone.
[14:41] <nic-doffay> this doesn't change no matter what unit amount I put.
[14:41] <nic-doffay> Any ideas?
[14:43] <tsdgeos> is it showing up maximized in the phone?
[14:43] <tsdgeos> what is big, the window or the things you draw?
[14:43] <mterry> fginther, so platform-api is raring-only in phablet-team/ppa, probably because it built when the configs were raring only.  How can we manually kick CI to rebuild packages for quantal?
[14:45] <fginther> sergiusens, ^^ We would need to create a release through a changelog update, correct?
[14:45] <smspillaz> kenvandine: lovely, I'll have a look
[14:45] <smspillaz> kenvandine: grrr, I hate it when this happens. Fix one app break another
[14:45] <kenvandine> hehe
[14:45] <kenvandine> smspillaz, thanks!
[14:46] <smspillaz> kenvandine: though tbh, if those Qt apps are setting StaticGravity then IMO they are broken
[14:46] <kenvandine> smspillaz, hopefully bisecting it for you will make it easy to fix :)
[14:46] <smspillaz> kenvandine: yeah, I know what the problem is, but I feel like its an app problem and not a window manager problem
[14:46] <kenvandine> perhaps qt should do that...
[14:46] <nic-doffay> tsdgeos, yeah maximum width
[14:46] <smspillaz> kenvandine: is this every Qt window ?
[14:46] <kenvandine> yes
[14:46] <tsdgeos> nic-doffay: probably becuse the phone runs it maximixed
[14:46] <kenvandine> that doesn't set the position
[14:47] <kenvandine> many of the qt examples set position to other than 0,0
[14:47] <kenvandine> those are fine
[14:47] <seb128> kenvandine, is that breakage in raring?
[14:47] <kenvandine> but if you drop that and try again
[14:47] <kenvandine> it breaks
[14:47] <smspillaz> kenvandine: seb128 just back it out
[14:47] <kenvandine> seb128, yes
[14:47] <nic-doffay> tsdgeos, can I disable this?
[14:47] <seb128> kenvandine, shrug :/
[14:47] <smspillaz> guake is not all that important
[14:47] <seb128> smspillaz, that will re-introduce the other bug though?
[14:47] <smspillaz> seb128: yep
[14:47] <smspillaz> sucks
[14:47] <kenvandine> the fix was for guake
[14:48] <smspillaz> yeah I know, guake is less important than this
[14:48] <tsdgeos> nic-doffay: no clue, to be honest, but just put another item on top of yours and then handle your item size on your own
[14:48] <seb128> kenvandine, why do you hate guake? :p
[14:48] <smspillaz> and I feel like this is going to be nontrivial
[14:48] <kenvandine> hehe
[14:48] <smspillaz> though maybe it won't be
[14:48] <tsdgeos> nic-doffay: did i made any sense there?
[14:48] <seb128> kenvandine, can you propose the revert? or talk to sil2100 about it?
[14:48] <kenvandine> sure
[14:48] <seb128> smspillaz, well, hard freeze is tomorrow, we better revert and try to fix it properly in a SRU?
[14:48] <smspillaz> makes sense
[14:49] <kenvandine> smspillaz, should i do that or maybe give you a few minutes to think about it?
[14:49] <smspillaz> seb128: I have an idea. If you'd prefer a proper fix I can quickly check if one will work
[14:49] <sergiusens> fginther: changelog needs to say quantal
[14:49] <nic-doffay> tsdgeos, I think so :P
[14:49] <Saviq> mzanetti, tsdgeos, hmm, qmlRegisterSingleton<T>(...) → it seems you can't pass that back to C++ :/
[14:49] <nic-doffay> giving it a go now.
[14:50] <kenvandine> smspillaz, ping me and i can confirm the fix
[14:50] <tsdgeos> Saviq: ¿?
[14:50] <sil2100> kenvandine, seb128: what seems to be the problem?
[14:50] <kenvandine> and if it isn't a quick fix
[14:50] <sergiusens> fginther: but give me a sec, this might get me the leverage to move to raring quicker
[14:50] <kenvandine> i'll revert
[14:50] <smspillaz> okay hang on
[14:50] <Saviq> tsdgeos, it comes back as QObject(0x0) :/
[14:50] <tsdgeos> Saviq: really?
[14:50] <kenvandine> sil2100, rev 3636 of lp:compiz/0.9.9 breaks qt apps
[14:50] <fginther> sergiusens, thanks
[14:50] <Saviq> tsdgeos, if I create the instance in QML
[14:50] <Saviq> tsdgeos, it comes back fine
[14:50] <tsdgeos> that's weird
[14:50] <kenvandine> window decorations behind the panel
[14:51]  * smspillaz hates working around all these broken applications
[14:51] <kenvandine> bug 1165343
[14:51] <smspillaz> kenvandine: actually, go ahead and revert it. I just realized that the only way we can fix it is to regress guake
[14:51] <nic-doffay> tsdgeos, as an example I tried moving the width and height to the child instead of the parent: https://pastebin.canonical.com/89362/
[14:51] <nic-doffay> Is this what you meant?
[14:51] <nic-doffay> Because I'm not seeing a change.
[14:51] <kenvandine> smspillaz, will do
[14:52] <sergiusens> fginther: well, it doesn't really matter as long as the devs do the changelog dance as they've been doing all along
[14:52] <tsdgeos> nic-doffay: that's what i meant
[14:52] <tsdgeos> nic-doffay: your code is "wrong" though
[14:52] <kenvandine> smspillaz, thanks!
[14:52]  * smspillaz represses some rage about broken applications that set _NET_FRAME_EXTENTS with StaticGravity
[14:52] <tsdgeos> nic-doffay: can't specify both width and height and say it has to fill the parent
[14:54] <smspillaz> (well _NET_REQUEST_FRAME_EXTENTS at least)
[14:54] <smspillaz> (that behaviour is just totally broken)
[14:54] <tsdgeos> Saviq: with qmlRegisterSingleton you mean qmlRegisterSingletonType ?
[14:54] <nic-doffay> Sorted tsdgeos
[14:54] <smspillaz> (why would you ask to have window decorations pre-allocated and then ask to be placed as though you didn't have them ... and then get rid of the window decorations)
[14:54] <tsdgeos> nic-doffay: cool
[14:54] <Saviq> tsdgeos, yeah
[14:55] <tsdgeos> Saviq: can i see the code?
[14:55] <Saviq> tsdgeos, sure, incoming
[15:01] <Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity/phablet.unity-test-module/+merge/159410
[15:05] <tsdgeos> Saviq: your callback function is wrong?
[15:05] <tsdgeos> has to be
[15:05] <tsdgeos> QJSValue (*callback)(QQmlEngine *, QJSEngine *)
[15:05] <Saviq> tsdgeos, it converts automagically
[15:06] <Saviq> tsdgeos, actually
[15:06] <Saviq> tsdgeos, there's two
[15:06] <tsdgeos> ah right
[15:06] <kenvandine> smspillaz, sil2100: https://code.launchpad.net/~ken-vandine/compiz/0.9.9.fix_1165343/+merge/159412
[15:06] <Saviq> tsdgeos, there's another one for QObject *(*callback)(QQmlEngine *, QJSEngine *)
[15:06] <kenvandine> i am going to reopen the bug it reverts the fix for
[15:07] <smspillaz> kenvandine: cool actually I just realized something
[15:07] <Saviq> tsdgeos, smells like a Qt bug, no?
[15:07] <smspillaz> kenvandine: along with the revert, decor.cpp:1571
[15:07]  * kenvandine listens
[15:07] <smspillaz> add another check w->isViewable ()
[15:08] <smspillaz> so w->frame () || w->isViewable () || w->hasUnmapReference ()
[15:08] <smspillaz> um
[15:08] <smspillaz> (w->frame () && w->isViewable ()) || w->hasUnmapReference ()
[15:08] <dandrader> Saviq, omg, it passed! https://code.launchpad.net/~dandrader/unity/phablet_remove_fakes_from_qml/+merge/158370
[15:08] <Saviq> dandrader, omg! ;)
[15:09] <sil2100> smspillaz, kenvandine: the revert itself looks fine to me, so I'll approve it in its current state - feel free to modify it later on
[15:09] <sil2100> Since I have to jump out for practice now
[15:09] <tsdgeos> Saviq: so the problem is that if you put TestUtil somewhere that is a property of a C++ object that pointer is 0?
[15:10] <Saviq> tsdgeos, if I pass the object to C++ it's 0
[15:10] <Saviq> tsdgeos, even if on QML side it's not
[15:10] <Saviq> tsdgeos, and even if an object created on the QML side is not, either
[15:10] <tsdgeos> Saviq: tried killing the "qmlRegisterType<TestUtil>(uri, 0, 1, "TestUtilObject"); // for debugging only" just in case?
[15:11] <kenvandine> -    const bool visible = (w->frame () ||
[15:11] <kenvandine> +    const bool visible = ((w->frame () && w->isViewable ()) ||
[15:11] <kenvandine>  		          w->hasUnmapReference ());
[15:11] <kenvandine> smspillaz, ^^
[15:11] <tsdgeos> shouldn't matter but
[15:11] <Saviq> tsdgeos, it wasn't there before
[15:11] <tsdgeos> ok
[15:11] <Saviq> tsdgeos, I only added it after I've discovered the issue
[15:11] <tsdgeos> yeah seems like you hit another bug :/
[15:11] <smspillaz> kenvandine: yep
[15:11] <tsdgeos> we shall create a testcase for it
[15:11] <Saviq> simple to reproduce at least
[15:11] <Saviq> tsdgeos, unless
[15:12] <Saviq> tsdgeos, it might be that I'm passing the object to itself
[15:12] <Saviq> but should work anyway
[15:12] <smspillaz> kenvandine: seems to work here with guake
[15:12] <tsdgeos> it should not matter yeah
[15:12] <smspillaz> kenvandine: can you check if that works with both guake and qt ?
[15:12] <kenvandine> sure
[15:12] <smspillaz> kenvandine: (do that along with the revert)
[15:12] <kenvandine> i can update the MP after i check it
[15:12] <kenvandine> yeah
[15:12] <smspillaz> yep
[15:14] <Saviq> tsdgeos, yeah, no difference
[15:14] <tsdgeos> Saviq: if you give me a testcase i can try it against 5.1
[15:15] <Saviq> tsdgeos, testcase? you not want too much? :P
[15:15] <Saviq> the Qt people...
[15:15] <tsdgeos> Saviq: or push something to that branch that uses it
[15:15] <tsdgeos> and tell me what to do
[15:16] <Saviq> tsdgeos, make testUnityTest
[15:16] <tsdgeos> in that branch?
[15:16] <Saviq> tsdgeos, yes
[15:16] <Saviq> tsdgeos, it is a testcase (not a Qt one, though)
[15:17] <tsdgeos> Saviq: i can't find where you're using TestUtil in QML in that branch?
[15:17] <Saviq> tsdgeos, did I not add the test file?
[15:17] <tsdgeos> http://bazaar.launchpad.net/~saviq/unity/phablet.unity-test-module/revision/616
[15:17] <Saviq> tsdgeos, pushed
[15:18] <Saviq> tsdgeos, sorry
[15:19] <tsdgeos> no worries
[15:19] <Saviq> tsdgeos, pushed some more debug
[15:20] <smspillaz> kenvandine: any results ?
[15:20] <kenvandine> smspillaz, still building :)
[15:20] <kenvandine> smspillaz, i always build packages and test
[15:20] <kenvandine> so no quick rebuilds
[15:21] <smspillaz> that is the one thing I dislike about debian packages
[15:21] <Saviq> tsdgeos, sounds related https://bugreports.qt-project.org/browse/QTBUG-30090
[15:21] <smspillaz> I would use a stronger word than "dislike" but I suspect that would start a fire
[15:21]  * smspillaz waves goodbye to like 50 tests
[15:23] <Saviq> tsdgeos, the only bug about qmlRegisterSingletonType
[15:23] <kenvandine> hehe
[15:24] <tsdgeos> Saviq: nah, still fails with 5.1
[15:24] <Saviq> tsdgeos, k, will build a simple test case tomorrow
[15:26] <smspillaz> kenvandine: btw, if you have a bug in compiz make sure to mark it as affecting the upstream "compiz" project
[15:26] <smspillaz> that way I'll see it
[15:26] <smspillaz> and squash it
[15:26] <kenvandine> smspillaz, will do!
[15:27] <mzanetti> Saviq: haven't ever used registerSingleton
[15:27] <mzanetti> re, btw
[15:27] <smspillaz> kenvandine: I'm going to propose a similar merge to lp:compiz which will effectively revert the relevant bits, keep the extra tests and add that isViewable check
[15:27] <Saviq> mzanetti, yeah, me neither, really just asking if I'm doing something stupid
[15:27] <mzanetti> Saviq: well, you're using a singleton, so probably you are...
[15:28] <kenvandine> smspillaz, cool, i noticed it wasn't trivial to revert that in trunk
[15:28] <Saviq> mzanetti, FU ;P
[15:28] <Saviq> mzanetti, but other than that, trying to save resources, ya know :P
[15:28] <mzanetti> Saviq: but no... can't give any useful info about singleton + qmlRegisterType
[15:28] <mzanetti> Saviq: that was trolling... I do well know where it makes sense
[15:28] <Saviq> ;)
[15:28] <Saviq> good
[15:32] <smspillaz> kenvandine: yeah there's another similar fix stacked on top
[15:32] <kenvandine> smspillaz, testing now
[15:33]  * smspillaz wishes the NBN would hurry up and arrive in perth, it takes too long to branch lp:compiz
[15:33] <smspillaz> #firstworldproblem
[15:36] <kenvandine> smspillaz, the additional check seems to have broken the qt apps again
[15:36] <kenvandine> but it did fix guake :)
[15:37] <smspillaz> kenvandine: ah really? hmm
[15:37] <smspillaz> kenvandine: what's an example qt app I can try quickly ?
[15:37] <kenvandine> friends-app
[15:37] <smspillaz> kenvandine: can I just apt-get install it ?
[15:37] <kenvandine> yeah
[15:38] <smspillaz> cool, lets see
[15:38]  * kenvandine waits
[15:40] <kenvandine> smspillaz, an even simpler test is http://paste.ubuntu.com/5716276/
[15:40] <kenvandine> save that to test.qml
[15:40] <kenvandine> and run it with qmlscene
[15:41] <smspillaz> cheers
[15:44] <Saviq> tsdgeos, actually got one now http://ubuntuone.com/6bdHFDTDRTktymrZsaO56w
[15:46] <tsdgeos> yep
[15:46] <tsdgeos> fails
[15:49] <smspillaz> kenvandine: hmm, well this is particularly lame
[15:51] <tsdgeos> QIntrusiveList
[15:51] <tsdgeos> nice name :D
[15:52] <smspillaz> kenvandine: I feel like this is tricky
[15:52] <smspillaz> kenvandine: setting the StaticGravity hint means "don't move this window around to accomadate its decorations"
[15:52] <smspillaz> and Qt is doing that
[15:53] <kenvandine> :/
[15:53] <smspillaz> and we have to run the placement rules before we set the decorations on the window
[15:54] <smspillaz> kenvandine: I mean, I could make an exception to the StaticGravity rule for windows that would effectively have their decorations be offscreen as a result of being decorated
[15:55] <kenvandine> smspillaz, from the qtbase5 source:
[15:55] <kenvandine>     // Determine gravity from initial position. Do not change
[15:55] <kenvandine>     // later as it will cause the window to move uncontrollably.
[15:55] <kenvandine> then it uses XCB_GRAVITY_STATIC
[15:56] <smspillaz> kenvandine: another option is to not revert, then give windows any relevant decorations before we run the placement rules
[15:57] <smspillaz> which kinda makes sense. When you're running the placement algorithm, having more information would work in your favor
[15:57] <Saviq> afk, more tomorrow
[15:57] <Saviq> cheers all!
[15:58] <smspillaz> kenvandine: I wouldn't suggest doing it that way for raring though, what I'm suggesting is a fairly big change
[15:59] <kenvandine> ok, so the revert for raring then?
[15:59] <kenvandine> without the decor.cpp change
[16:01] <smspillaz> kenvandine: yeah do that for now
[16:02] <kenvandine> ok
[16:02] <smspillaz> kenvandine: I just noticed that what I'm suggesting is actually relatively simple, but I need to check if it works and give it some time to check for other potential regressions too
[16:02] <kenvandine> smspillaz, ok, i just pushed my branch again
[16:08] <smspillaz> kenvandine: actually, I'm starting to think more and more that Qt setting XCB_GRAVITY_STATIC is what's really broken here
[16:08] <smspillaz> the problem with guake was that its a normal window, hasn't yet undecorated itself, yet explicitly asked us not to consider its decorations when placing it
[16:08] <smspillaz> but Qt is basically doing the exact same thing, except that it intends to retain its decoratiosn
[16:09] <kenvandine> smspillaz, perhaps, but based on that comment it looks like they did that for a reason
[16:09] <smspillaz> kenvandine: well, the comment just said "we are basing the geometry of the window based on its gravity ... don't change this later"
[16:09] <kenvandine> we could also patch qtbase5
[16:09] <smspillaz> kenvandine: would you happen to know the person to talk to in qt ?
[16:10] <kenvandine> Mirv, ^^
[16:10] <kenvandine> Mirv  maintains our packages
[16:10] <smspillaz> the other thing is that metacity and friends must implement some kind of workaround for this
[16:10] <kenvandine> smspillaz, beyond that, i have no idea :)
[16:10] <didrocks> fginther: not sure what happened, but unity next was uploaded to the daily-build-next ppa :/
[16:10] <didrocks> fginther: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next
[16:10] <didrocks> fginther: we are goint to push the unity compiz on it, I'm removing it
[16:11] <kenvandine> smspillaz, what would you suggest besides XCB_GRAVITY_STATIC?
[16:11] <didrocks> fginther: same from unity-lens-mock
[16:11] <smspillaz> kenvandine: XCB_GRAVITY_NORTHWEST
[16:11] <didrocks> and libunity
[16:11] <didrocks> fginther: /!\ urgent, remove that
[16:12] <didrocks> mterry: do you mind following that up with fginther once he's back?
[16:12] <kenvandine> smspillaz, http://paste.ubuntu.com/5716339/
[16:12] <didrocks> mterry: and eventually, remove what we should meanwhile
[16:12] <didrocks> (I removed the 3 I mentionned)
[16:12] <fginther> didrocks, I'm a little confused, do you need me to remove them?
[16:12] <kenvandine> says adapt geometry to match the WM expectations :)
[16:13] <didrocks> fginther: you shouldn't dput them in raring
[16:13] <didrocks> fginther: the daily release is doing it
[16:13] <fginther> didrocks, it came from CI? that's news to me
[16:13] <didrocks> fginther: seems so
[16:14] <fginther> didrocks, I'll dig into it
[16:14] <didrocks>  unity - 7.81~phablet1bzr3258raring0
[16:14] <didrocks> fginther: the version seems ci-ish? ^ :)
[16:14] <fginther> didrocks, true
[16:16] <kenvandine> smspillaz, although it does look like it might do the right thing if i default it to northwest
[16:26] <didrocks> kenvandine: for lp:compiz, do you know what to do?
[16:26] <didrocks> kenvandine: with your branch
[16:27] <kenvandine> didrocks, no, the revert isn't as trivial there
[16:27] <kenvandine> there are more stacked changes on top of the same code
[16:28] <kenvandine> while waiting for CI to run again, i am doing a build of a patched qtbase5 too
[16:29] <smspillaz> didrocks: leave lp:compiz alone for now, I need more time to think about this
[16:29] <smspillaz> and I don't want users of other apps (namely guake) complaining
[16:31] <didrocks> smspillaz: ok, can you get it written somewhere so that we don't forget about it?
[16:31] <didrocks> smspillaz: well, I think ken will notice the regression :p
[16:31] <kenvandine> :)
[16:31] <didrocks> so maybe that's enough to rely on kenvandine seeing it ;)
[16:31]  * smspillaz throws a knife at the ICCCM
[16:32] <kenvandine> the sdk guys will notice quickly too... it just took us a long time before blaming compiz :)
[16:32] <smspillaz> I still think the sdk behaviour is questionable at best
[16:32] <smspillaz> I'm just trying to figure out why it works with other window managers
[16:35] <mterry> fginther, I manually copied those packages over, my fault
[16:35] <mterry> fginther, I should have checked with didrocks
[16:36] <fginther> mterry, ahhhh. no worries, I was having some serious problems tracking it down ;-)
[16:37] <mterry> fginther, sorry :-/
[16:37] <kgunn> mzanetti: ping
[16:38] <mzanetti> kgunn: pong
[16:43] <kgunn> dednick: ping
[16:46] <smspillaz> ah interesting, the other window managers don't work the way I think they do
[16:46] <kgunn> nic-doffay: ping
[16:49] <mterry> fginther, I did see you retrying the arches branch a few times
[16:49] <mterry> fginther, any luck there?
[17:01] <didrocks> tedg: see, changing the name of the maintainer for yours is failing :) jenkins is rejecting you! :)
[17:01] <didrocks> mterry: phew, you made me afraid :)
[17:01] <didrocks> mterry: we are not going to land unity next in it at first
[17:07] <dednick> kgunn: pong
[17:14] <smspillaz> kenvandine: ok, so I have something that fixes qt, guake and others
[17:14] <smspillaz> though it feels weird
[17:14] <smspillaz> although, based on what I've read (and observed) with other window managers, the behaviour I'm doing seeks to be OK
[17:15] <didrocks> mterry: oh, as well, do you mind closely look at https://code.launchpad.net/~mandel/unity/plan-b/+merge/158383, it needs to get merged for tomorrow daily release
[17:15] <didrocks> fginther: as well ^
[17:15] <didrocks> (thanks!)
[17:15] <smspillaz> kenvandine: basically, I've made it so that if you get undecorated (and aren't maximized) you get repositioned as though you were the same size as if you had decorations
[17:15] <smspillaz> kenvandine: does that seem sane to you ?
[17:15] <smspillaz> (this is basically what kwin does)
[17:16] <smspillaz> metacity does something else, but that feels really broken, you basically just lose the decorations and end up with blank space above you
[18:24] <fginther> mterry, is it safe to split a project branch into a raring branch at any time? Even if  there are recent changes in trunk that have not yet been released?
[18:25] <mterry> fginther, depends?  Do you want those changes in raring or not?
[18:25] <mterry> fginther, just depends on where in trunk you split I guess
[18:26] <fginther> mterry, yes they need to be in raring. The changes have been merged, but daily release has not run on them yet
[18:26] <mterry> fginther, so sure, split off raring and both branches will have the changes
[18:26] <fginther> mterry, excellent, that was my assumption.
[18:29] <fginther> mterry, cyphermox, one of you will need to deploy this when ready, correct? https://code.launchpad.net/~bregma/cupstream2distro-config/oif-raring-split/+merge/159461
[18:31] <mterry> fginther, yeah, but didrocks still needs to do final deployment (we need an archive-admin to do that)
[18:31] <mterry> bregma, why are there target_branch entries in raring in that branch?  Wouldn't everything move to head?
[18:39] <fginther> mterry, the raring stacks get the maintenance branches and head gets the trunk branches, correct?
[18:40] <mterry> fginther, yeah
[19:15] <cyphermox> fginther: commented
[19:26] <alecu> fginther: hi, thanks for the help yesterday fixing the jenkins issue. One more question: in lp:unity is it tarmac that takes care of landing branches with "Status: Approved"? I'm guessing that it might take some time for them to be landed, but I just wanted to make sure.
[19:27] <alecu> (I'm asking about the same branch as I asked yesterday: https://code.launchpad.net/~mandel/unity/plan-b/+merge/158383 )
[19:27] <fginther> alecu, we use a jenkins process similar to the -ci jobs to do the merge
[19:28] <fginther> alecu, that branch is building right now
[19:28] <alecu> excellent!
[19:32] <cyphermox> fginther: are you saying there are some changes in the oif stack that need to land ?
[19:33] <fginther> cyphermox, they have been merged into trunk, but daily release has not run on them yet
[19:33] <cyphermox> fginther: mterry: I'll deploy the stuff in cu2d once it's mrged.
[19:33] <cyphermox> ok
[19:33] <cyphermox> and it's stuff that needs to land in raring?
[19:33] <cyphermox> fixing release critical bugs?
[19:33] <fginther> cyphermox, that's a question for bregma
[19:43] <fginther> bregma, ping
[20:16] <bregma> well, there's a major fix to libgrip that should land, the symptom being "it doesn't work"
[20:17] <bregma> same for the geisview tool in geis, but that's a lower priority since it's really only for diagnostics
[20:19] <fginther> alecu, plan-b has merged
[20:19] <alecu> fginther: great!
[20:20] <alecu> fginther: this means that it will be released in tomorrow's unity package, right?
[20:21] <fginther> alecu, yes (as long as all the pieces work)
[20:24] <fginther> bregma, I approved the oif-raring-split mp and will deploy the upstream jobs once it merges
[20:26] <fginther> bregma, didrocks will have to do the final step to get this update into the daily release process
[20:57] <bregma> thanks
[21:09] <kgunn> mterry: ping
[21:10] <mterry> kgunn, hi
[21:55] <SveinT> anyone else here having problems with blur enabled on the Dash?
[21:55] <SveinT> performance got horrible from 12.10 to 13.04