=== _salem is now known as salem_ === salem_ is now known as _salem [07:04] Cimi, ping [07:34] 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] 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] or the other way round [07:39] if you say no, you didn't change the code, I'm lost too [07:40] ah, that might make sense [07:40] the modeltest was pushed a bit later [07:40] huh... luckily... those kind of things really scare me [07:40] so yeah [07:41] what do we do here? [07:41] Saviq: ping? [07:41] tsdgeos, here [07:41] looking [07:41] 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] Saviq: the copyright checked is complaining [07:42] checked/checker [07:42] tsdgeos, that's because you didn't include the actual license [07:42] here the MR https://code.launchpad.net/~aacid/unity/sortfilterproxymodelqml_split/+merge/159174 [07:42] tsdgeos, $QT_BEGIN_LICENSE:LGPL$ [07:42] Saviq: well I copied the file verbatim from the repos [07:42] tsdgeos, exactly [07:42] tsdgeos, you need to take it from a tarball [07:43] where that var is replaced with the actual license [07:43] tsdgeos, but then... [07:43] tsdgeos, can we actually put it with our code? [07:44] it's LGPL [07:44] i don't see why not [07:45] what's your concern? [07:48] tsdgeos, well, it's tests, so we're not really going to distribute it in binary to anyone [07:50] tsdgeos, but IANAL... [07:50] still [07:50] tsdgeos, at the very least, update debian/copyright [07:50] LGPL is just compatible with everything we use [07:50] tsdgeos, not if we later want to ship it under a commercial license [07:51] +or need [07:51] it is still commercial "friendly" [07:51] just requires you to release the changes to that file [07:51] which are 0 [07:51] and as you said, it's a test, we don't even need to distribute it binarily to people [07:52] Saviq: i downloaded the tarball, the file is exactly the same, still hsa that $QT_BEGIN_LICENSE:LGPL$ [07:52] tsdgeos, huh [07:52] well, what did you expect? [07:52] the license is already there [07:53] lines 17 and down [07:53] ah ok [07:53] so $...$ are just markers [07:53] not vars [07:54] yep [07:54] tsdgeos, then we need to add a licensecheck-compatible line in the comment there [07:55] that'd be modifying the file and meaning we have to distribute the changes :D [07:55] oh actually no [07:55] we can assume gpl3 [07:55] and since it's a test who cares [07:55] and the header is not under copyright [07:57] tsdgeos, apt-get install devscripts [07:57] tsdgeos, and make the copyright header pass [07:57] +test [07:57] tsdgeos, and run tests locally before submitting :P [07:57] at least the test target [07:57] sure [07:58] i'd tell you i had done that [07:58] but i didn't [07:58] but still, it passes [07:58] http://paste.kde.org/~tsdgeos/726206/ [07:58] otoh don't see any copytight check in there [07:58] tsdgeos, right, because it's not merged yet [07:59] tsdgeos, the copyright check is part of jenkins jobs for now [07:59] Saviq: totally my fault for not running the tests [07:59] i see [08:00] tsdgeos, gotcha ;) [08:00] tsdgeos, but you can use licensecheck from devscripts [08:00] yep [08:00] tsdgeos, something like `licensecheck -r . | grep -v -F ./builddir | grep "No copyright"` [08:00] the .sci files are ignored later [08:01] or i can do [08:01] licensecheck tests/unittests/plugins/Utils/modeltest.cpp [08:01] and that's it :D [08:01] i just added a few files [08:02] mzanetti, hi. have you had time to check this autopilot issue I e-mailed you about? [08:03] 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] well... maybe not directly the solution. but can definitely help you [08:04] mzanetti, awesome! thanks! [08:07] dandrader, DUDE! don't you sleep!? [08:07] 5am!? really? [08:10] Saviq, yeah. woke up early so that I can go climbing in the afternoon :) [08:11] dandrader, nice [08:11] dandrader, but then... [08:11] 5am!? really? [08:11] ;) [08:11] Saviq: I keep on wondering too [08:11] :) [08:11] actually, I started at 04:30 :) [08:11] dandrader: I'd have time for you now [08:12] lets not flood the channel... [08:16] Saviq: http://bazaar.launchpad.net/~aacid/unity/sortfilterproxymodelqml_split/revision/611 and http://bazaar.launchpad.net/~aacid/unity/sortfilterproxymodelqml_split/revision/612 [08:17] tsdgeos, yup, looks good [08:21] he [08:21] Found 2 license prolems: [08:21] tests/unittests/plugins/Utils/modeltest.h LGPL (v2.1) 2013 Digia Plc and/or its subsidiary(-ies) [08:21] tests/unittests/plugins/Utils/modeltest.cpp LGPL (v2.1) 2013 Digia Plc and/or its subsidiary(-ies) [08:22] Houston, we have a prolem [08:23] Saviq: shall i simply remove the code and be happy with worse testing? [08:23] tsdgeos, so it seems licensecheck checks for Canonical copyright explicitly? [08:23] not on my machine [08:24] but maybe on whatever that is runninng [08:24] tsdgeos, yeah, it's set up so on jenkins, probably [08:24] mzanetti, can you shed some light ^? [08:24] * mzanetti reads backlog [08:24] hehe [08:24] * mzanetti adds Digia to the list of allowed licenses [08:25] tsdgeos, see :) [08:28] Saviq: tsdgeos: https://code.launchpad.net/~mzanetti/pbuilderjenkins/add-digia-license/+merge/159319 [08:41] reboot [08:42] uhoh [08:42] my kernel is oopsing [08:42] in audio related stuff [08:42] did my HW just break?¿ [08:45] sil2100: hey, what's the news on the street? on what are you working on? :) [08:45] 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] sil2100: so we can't run autopilot… [08:49] didrocks: hi! I have been continuuing some testing regarding HUD unit tests reliability and checking on merges and their failures [08:49] didrocks: which branch do you have in mind? [08:49] The one with AP fixes for raring? [08:49] (armhf seems failing there for unknown reasons for me...) [08:49] sil2100: this one, but in paticular all the "add all the packages for autopilot to run" [08:50] sil2100: great! Keep hacking on the HUD, would be great to have something passing today ;) [08:51] I also hope https://code.launchpad.net/~robru/camera-app/packaging/+merge/153651 will get in pretty soon! [08:53] sil2100: yeah, did you see the questions? if you have more QML knowledge than I… [08:53] 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] On which fginther was working I think? [08:53] sil2100: right, I don't know where fginther is with this [08:53] sil2100: if you don't mind tracking it :) [08:54] 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] sil2100: excellent, thanks! [08:58] didrocks: just got some foundations laid so that we can do acceptance tests on compiz plugins [08:58] which is awesome [08:59] smspillaz: oh! excellent news :) acceptance tests needs a UI though? [08:59] didrocks: xorg-gtest [09:00] 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] so we can run them as a CI job [09:00] smspillaz: ah, even better :) [09:00] yep, been hoping to have that for a while [09:01] smspillaz: this should be even some autopkgtests :) [09:01] for debian and ubuntu [09:01] 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] smspillaz: yeah ;) [09:01] and the oops went away [09:01] now i don't know if the HW is half dead or the SW is half broken :-/ [09:01] didrocks: well, it should work as an autopkgtest as long as it works in CI. iirc xorg-gtest was in main now [09:02] smspillaz: autopkgtests are running against the installed version of your software [09:02] smspillaz: so it needs tweaking to support that :) [09:02] smspillaz: those are triggered when a reverse dependency is uploaded for instance [09:02] didrocks: ah I see. I think that probably makes more sense for autopilot then [09:03] hmm [09:03] smspillaz: it's different from autopilot, but I agree the lines are not quite clear [09:03] yeah I can see the difference, I'm just wondering what the implementation would look like [09:04] yeah, quite hard to decipher some guidances [09:04] yould probably do it, you'd just need to "install" the test binaries or something [09:04] *you could probably [09:05] smspillaz, hey Sam! [09:05] howdy [09:06] MacSlow: how goes things? [09:06] smspillaz, very busy :) [09:06] I can imagine ;-) [09:16] mzanetti: i guess it'll take a while until that Digia fix gets to the jenkins slaves? [09:16] tsdgeos: I have to apt-update and install it on all nodes manually :/ [09:16] really?¿ [09:16] ouch [09:17] yeah... [09:17] I think there was an approach to use landscape for the jenkins nodes. not sure why thats not the case any more [09:18] tsdgeos: well... there might be a cron job that updates the pbuilderjenkins package nightly... but that won't happen before tomorrow [09:18] he he [09:19] 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] mzanetti: i guess it can wait [09:20] didrocks: anything else I can help with in-between test runs? [09:20] tsdgeos: ok... in case it kepps on failing after a reasonable amount of time, ping me and I'll update [09:20] sil2100: plenty of things! :) one sec [09:21] :) [09:29] sil2100: do you want to do a hangout? [09:29] (a quick one) [09:32] Oh boy... didn't migrate to chromium yet! Is screensharing needed ;)? If it's not crucial, I could [09:32] sil2100: no screensharing I guess [09:32] didrocks: ok, ready when you are then [09:33] sil2100: https://plus.google.com/hangouts/_/3a7c0c16c2cce6a379d806887326c30f5e5388ac?authuser=0&hl=it [09:36] 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] tsdgeos: it does not here... but I can't spot the difference to trunk - which works here [09:38] mzanetti: device or pc? [09:38] pc [09:39] doing [09:43] mzanetti: seems to work here [09:43] what problem are you having exacly? [09:44] tsdgeos: any hints what could be wrong here? [09:44] tsdgeos: ./run'ing trunk works fine here, but on this one it just doesn't load any dash [09:44] tsdgeos: I already deleted builddir and built again [09:45] mzanetti: so you get a totally empty thing after opening the greeter? [09:46] tsdgeos: yes [09:46] 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] tsdgeos: I tried that too... says nothing to merge [09:47] I tried the other way round tho... cloned that branch and merged trunk into it [09:49] mzanetti, I tried the set_target_properties() [09:49] mzanetti, that doesn't get populated to the dependant targets [09:50] mzanetti, and I agree on the cmake module, thought of that myself, and will do [09:50] Saviq: oh... that sucks... but afaics we would only need it on the real ctest ones... [09:50] Saviq: because the others are verbose themselves... while only make check uses ctest and hides output [09:50] mzanetti, we would need to set it up on each add_test() manually :/ [09:50] ok... skip it then... [09:51] mzanetti, I have creating a dummy Makefile in our root on my TODO [09:51] mzanetti, that will forward whatever to builddir [09:51] uuhhh! nice one! [09:51] mzanetti, and we can then put the env there [09:52] +1 [09:52] ok, so .cmake is remaining [09:54] mzanetti: ran it on the device, works fine too [09:54] mzanetti: honestly no idea how to debug it :-/ [09:56] tsdgeos: ok... thanks... [09:56] can I help? [09:56] mzanetti: other than adding a million printfs of course :D [09:56] Saviq: https://code.launchpad.net/~mterry/unity/phablet-greeter-lightdm/+merge/158245 [09:57] Saviq: running this on my PC does not load any lenses [09:57] Saviq: running trunk on my PC works fine [09:57] Saviq: says nothing to be merged [09:58] mzanetti, checking [09:58] Saviq: well, it works on tsdgeos's machine... so probably something locally here... I would still like to understand whats happening [09:58] but not really sure how to approach [09:59] mzanetti: which sdk do you have? [09:59] tsdgeos: sdk? [09:59] mzanetti, tried ./build_unity -c? I wonder if it's related to your having libunity installed [09:59] qtdeclarative5-ubuntu-ui-toolkit-plugin [09:59] 0.1.42~raring1 ? [09:59] mzanetti: ↑↑ [10:00] tsdgeos: same here [10:00] Saviq: no, didn't try [10:00] Saviq: still wouldn't explain trunk working, would it? (as the MP doesn't seem to change that part) [10:00] mzanetti: ok [10:00] mzanetti, true [10:01] mzanetti, works here [10:01] mzanetti, any interesting output on the console? [10:02] Saviq: nope. exactly the same except warnings caused by lenses are missing [10:05] mzanetti, no idea here [10:05] mzanetti, I'd go for a rm -R ../unity_build [10:05] and start over [10:05] 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] mzanetti: just in case this is what i have http://paste.kde.org/~tsdgeos/726320/ [10:06] tsdgeos: the lightdm part is the only thing working :D [10:06] anyways, thanks [10:07] i know, but won't hurt to install a few packages :D [10:19] 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] (I took an aspirin btw) [10:19] Cimi, no, it was about yesterday's talk about dee in the mock plugin [10:20] Saviq, ok tell me [10:20] Cimi, there can be no dee in there, you just need a ListMOdel [10:20] Cimi, so you need to create/use something that's based on QAbstractListModel [10:20] Saviq, but it's categories from the c++ plugin? [10:20] ah ok [10:20] Cimi, it doesn't care about dee [10:20] ok [10:20] Cimi, it's an implementation detail the tests can't know about [10:25] Cimi: you need DeeVariantText in a test? [10:25] mzanetti, I need a list modelk [10:25] mzanetti, lens.categories [10:26] 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] 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] mzanetti, and thought it was required the same [10:27] also I need to see how to write a model in c++ [10:28] 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] mzanetti, uh, add_custom_target(check DEPENDS test) doesn't work... [10:30] freakin' test isn't a normal target [10:30] at least not under make (it worked under ninja... [10:31] hmpf... [10:33] but I did try to debuild it... [10:33] * Saviq tries again [10:35] hmm it works [10:36] * Saviq doesn't get it [10:38] mzanetti, why the --force-yes? [10:44] Saviq: already delete the branch again [10:44] Saviq: it kept on failing here... but while editing the comment in the MP I flashed todays image and it worked again [10:45] mzanetti, k [10:45] mzanetti, seem dh_auto_test actually uses the test target (at least for CMake projects) [10:46] mzanetti, so the custom target wasn't helping anyway [10:46] and the failures were silent anyway [10:47] and! [10:47] it sets CTEST_OUTPUT_ON_FAILURE by itself [10:48] so we can get rid of the check target altogether [10:49] yup [10:50] Saviq: yeah... the check target was just to keep syntax compatible to googletest, right? [10:50] I haven't seen that before either.... [10:50] mzanetti, I thought it was about debhelper... [10:50] didrocks, question - why the "check" target? [10:50] but jenkins executes "make check || make test" anyways... so fine with me [10:51] Saviq: sorry, out of context, what check target? :) [10:51] Saviq: jenkins merger? [10:51] didrocks, no, in general [10:51] didrocks, we had a custom "check" target in CMake [10:51] for compatibility with... [10:51] something [10:51] I thought it was about dh [10:52] Saviq: so in the dash search we still have that occasional crash on search [10:52] 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] didrocks, actually dh runs make test [10:52] i've checked and going to carousel+listview+patches still crashes [10:52] didrocks, at least under CMake [10:52] so it's unrelated [10:52] not sure if carousel at all or not [10:52] Saviq: right, it depends on the build tool [10:52] tsdgeos, uhm, was hoping it is [10:52] nah [10:52] the bt is weeeeird [10:53] Saviq: autotools are more "make check": http://www.sourceware.org/autobook/autobook/autobook_98.html [10:53] 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] http://paste.kde.org/~tsdgeos/726350/ [10:53] QQuickWindowIncubationController::incubate [10:53] tsdgeos, that I never saw... [10:53] what's a incubation controller? :D [10:53] Saviq: if you have a make test, that's fine, use that one :) [10:53] didrocks, \o/ [10:53] Saviq: ah because you where not running with your own Qt so you didn't see the assert but the crash probably [10:53] which may have been a bit different [10:54] Saviq: let me just recheck that dh_tests is indeed running that one as well for cmake [10:54] didrocks, sbuild didn't complain [10:54] tsdgeos, yeah, probably [10:54] when running with the system qt i get http://paste.kde.org/~tsdgeos/726356/ [10:54] Saviq: ↑ [10:54] Saviq: didn't complain != run :p [10:54] didrocks, it did run the tests, yes [10:55] Saviq: but yeah, dh_auto_test is running make test and make check, depending on what it found in the makefile [10:55] didrocks, ah, smarts! [10:55] didrocks, awesome, thanks [10:55] Saviq: yw ;) [10:55] tsdgeos, not even, I think [10:55] ok [10:55] tsdgeos, so it might actually be related (i.e. you fixed one thing, but there's another happening anyway) [10:56] yeah [10:56] this one gonna be harder i think [10:56] mzanetti, will you tell me I should split out the cmake stuff out of that MP? (/me cries away for git) [10:57] Saviq: huh? [10:57] Saviq: from the flatten-qmltests one? [10:57] mzanetti, yes [10:57] why that? [10:57] mzanetti, 'cause it's not really related ;) [10:57] no... just merge it as is... history isn't worth a thing with bzr anyways [10:58] indeed [10:58] mzanetti, what targets to we want "forwarded" to builddir? [10:58] alltests [10:58] autopilot [10:58] hmm.... thats the ones I use the most [11:00] Saviq: can you please check lines 1244 and 1257 in here https://code.launchpad.net/~mterry/unity/phablet-greeter-lightdm/+merge/158245 [11:00] Saviq: I think there is something fishy - we should not need this [11:00] mzanetti, indeed [11:01] besides the mock should probably live somewhere in tests/ not plugins/ [11:01] mzanetti, I'm thinking the plugin links to the mocks [11:01] mzanetti, which are separate .so [11:01] which would, of course, be bad [11:01] yeah... I guess so... [11:03] mzanetti, is there a MP from you fixing the path/LD in autopilot? [11:03] Saviq: no...... only the builddir thingie... [11:04] Saviq: but I can do [11:04] mzanetti, could there be? [11:04] yea [11:04] mzanetti, yes please [11:04] mzanetti, not sure about fixing it _in_ the .py, too [11:04] Saviq: where else? [11:04] mzanetti, it's only relevant for local builds [11:05] yeah... the py distinguishes between local and installed builds [11:05] mzanetti, ok, more local [11:05] mzanetti, as in: if you have the deps installed [11:05] mzanetti, the LD isn't required [11:05] even though you build locally [11:05] my case, that is [11:05] yes ;) [11:06] so I wonder if the Makefile I'm writing now could have bearing here [11:09] mzanetti, with http://pastebin.ubuntu.com/5715632/ [11:09] mzanetti, make autopilot works here [11:10] * Saviq needs to learn Ninja to do the same for it [11:11] Saviq: what if you execute "make autopilot" within the build dir? [11:11] mzanetti, it won't [11:11] of course [11:11] mzanetti, but if you go ./qml-phone-shell in the build dir [11:11] mzanetti, it will fail just as well [11:12] mzanetti, is there any way to known if ci is building (or is scheduled to build) my merge proposal? [11:12] mzanetti, but it's temporary [11:12] * dandrader is anxious [11:12] dandrader, http://s-jenkins:8080/job/unity-phablet-ci/ [11:13] dandrader, you need to look through the running jobs [11:13] dandrader, and look at their parameters [11:13] there's a link on the left [11:13] dandrader, http://s-jenkins:8080/job/unity-phablet-ci/583/parameters/? [11:13] dandrader: yeah... open parameters and then just use the "Previous build"/"Next build" links [11:14] mzanetti, Saviq excellent! thanks! [11:15] jesus.. it takes time "Started 42 min ago" [11:15] Saviq: I'm fine with it... if you're fine with it we're good I'd say [11:15] dandrader, it's most probably queued === MacSlow is now known as MacSlow|lunch [11:16] dandrader: hmm... let me check what's blocking the queue [11:16] dandrader, http://10.97.2.10:8080/job/unity-phablet-qmluitests/ [11:16] mzanetti, http://10.97.2.10:8080/job/unity-phablet-qmluitests/376/console hangs [11:19] 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] mzanetti, beat me to it [11:20] damn whitespace... [11:21] dandrader, http://vim.wikia.com/wiki/Highlight_unwanted_spaces ;) [11:21] dandrader, also, MAKE TEST! ;P [11:23] I have a "set listchars" for that but it doesn't seem to be working so well [11:30] mzanetti, pushed the Makefile === dandrader is now known as dandrader|lunch [11:30] Saviq: pushed to where? [11:30] mzanetti, same branch [11:31] Saviq: you sure? [11:31] no [11:31] mzanetti, now [11:34]