[04:50] smspillaz: in and out :) [04:51] slangasek: coolio. I replied to your merge review and uploaded a revised version [04:51] s/your/my/ [04:51] (that you were reviewing) [04:54] smspillaz: cool; I probably won't have a chance to take a look tonight, but will take another gander tomorrow [04:55] no problem. [04:55] there's one more EXPECT_EQ missing, I'll keep looking for it [07:18] sil2100: hey, how are you? [07:42] didrocks: hi! More or less good, how about you? [07:42] https://code.launchpad.net/~sil2100/unity/autopilot_disable_screen_lock/+merge/158989 <- can anyone re-review? [07:42] sil2100: I'm ok, thanks [07:43] sil2100: did you talk with thomi? mayb e francis should have a look? not sure who else [07:43] sil2100: the gsettings part is fine [07:43] sil2100: not sure about the autopilot part [07:44] sil2100: commented with what I told above ^ [07:44] sil2100: on another topic, what's up? can we add more stacks to daily release? did you get any progress on the packages we install from autopilot? and what about the HUD? [07:47] didrocks: yes, been trying to check why the HUD tests are failing again, Mathieau asked me to look into those and sadly it's not a timeout issue this time [07:47] sil2100: and on the #1 issue, which was about the stacks and so on? [07:52] sil2100: ? ^ [07:53] didrocks: ah, sorry, had a few discussions just now [07:53] didrocks: so, in overall: [07:56] didrocks: I was browsing the rdepends of packages to install for the stacks testing, and it seems there's not much we can cut up, the xcb libraries are necessary for qt gui to work, and the other non-qt dependencies are generally for hud - while on mysql I still didn't get a definite answer from upstream, but I'm still poking [07:57] didrocks: I prepared some stack additions for teh moment when robru's branches get in, but there's still one pacakging review branch that doesn't build properly (you saw the build-depends issue) [07:57] sil2100: ok, can you list that somewhere and maybe add the depends we really need for sure (apart from mysql) [07:57] sil2100: maybe Mirv can look at the mysql part? ^ [07:57] so that you can advance on the rest [07:57] didrocks: I have it on my branch, waiting for Mirv to comment [07:57] ok [08:00] I still need clarification, since libqt5sql5 pulls libqt5sql5-mysql strangely in, since I saw that control has in Recommends such a thing: libqt5sql5-mysql | libqt5sql5-odbc | libqt5sql5-psql | libqt5sql5-sqlite | libqt5sql5-ibase [amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sh4 sparc] [08:01] Shouldn't libqt5sql5-sqlite be sufficient for him? [08:02] sil2100: yeah, but it's picking the first of the list if nothing is installed before [08:02] sil2100: so if the requirement of libqt5sql5 is before something pulling libqt5sql5-sqlite, it will take the mysql one [08:03] sil2100: actually, I think on that list, libqt5sql5-sqlite should be first [08:03] didrocks: yes, that's what just popped in my head now as well [08:03] then, if someone wants another sql, he needs to explicitely specify it [08:03] it's like, "the lighter first" [08:03] Mirv: there are some qt5 package in the ppa, mind making this change? ^ [08:03] Anyway, if we add it to the list od packages in the stack, i.e. libqt5sql5-sqlite, it shouldn't pull in mysql then anyway, right? Since sqlite will be installed first? [08:03] or sil2100 ^ [08:04] Since I've been wondering if that works like this [08:04] sil2100: hum, if it's first, right, but I would anyway fix the dep order as well [08:04] the recommends* order rather [08:04] Right [08:04] Mirv: ^ (poked here and everywhere) [08:05] I think it's alright as discussed #elsewhere :) [08:06] sqlite is probably the best first option [08:07] sil2100: Mirv: not sure you have upload rights to the ppa, but a debdiff will be good :) [08:08] * sil2100 checks that ;p [08:09] sil2100: I can indeed fetch your debdiff, apply and upload [08:10] Mirv: you need to do the same in the ubuntu-unity/daily-build-next ppa as well I guess as I told [08:10] Mirv: I think mterry uploaded there a difference version of qt5 [08:11] mzanetti, did you try and run the autopilot tests locally recently? after having fixed the path, it seems hang [08:11] +to [08:11] mterry had the same [08:12] didrocks: ah, so it seems, I hadn't heard anything about that [08:12] also, I've now 5.0.2 packaging but I'll have a separate 5.0.1 one [08:13] didrocks: I think I'm not part of the team ;) [08:16] hmm, mterry doesn't seem to have his packaging changes in any bzr [08:17] Yes, that's why I fetched the sources from the PPA... [08:17] Mirv: do you mind checking up with him and resync all this if needed? [08:18] didrocks: well I can take the debian.tar.gz, diff against clean packaging, check the changes and get them to both 5.0.2 and 5.0.1 [08:18] and surely also chat a bit when he wakes up [08:21] Mirv: should I send you the debdiff? [08:22] sil2100: yes if you had something on top of 5.0.1+dfsg-0ubuntu5~xembed3, but no otherwise [08:23] I could push the modified qt package to the next PPA, but it seems I have no permissions [08:23] I can change the sql order anyhow [08:23] Mirv: right, it's a trivial change anyway [08:28] Saviq: by running "make autopilot" you mean? [08:29] mzanetti, actually by going "autopilot run ...." [08:29] mzanetti, but yeah, make autopilot fails due to a wrong path [08:29] Saviq: yeah... they broke when forbidding in-source builds [08:31] mzanetti, but that's easily fixed, the fact that it hangs is a bit more troubling [08:32] Saviq: does it hang forever? I think autopilot has a timeout and gives up [08:32] mzanetti, well yeah, it gives up [08:33] Saviq: ah... after fixing the path they hang... I see [08:33] yup [08:33] Saviq: iirc I checked mterry's branch and came to the conclusion it was caused by a change in his branch... but let me try with trunk... its already more than a week ago [08:34] didrocks: btw. is there a nice command that could tell me which package 'conflict' with a given package? [08:36] Saviq: hmm... they don't hang here... they do fail tho [08:36] mzanetti, what's your res? [08:36] * mzanetti wonders why they pass in jenkins [08:37] Saviq: 2880x1800 [08:37] mzanetti, yeah, that might be why it hangs here, I'm at a humble 1600x900 [08:37] jeez dude [08:38] yeah..... and then there are people wanting me to force to use only 80 cols in my text editor [08:38] thats smaller than the panel [08:38] :D [08:39] Saviq: still... it shouldn't hang because of the resolution [08:39] rotfl [08:41] Saviq: can you please just run 1 autopilot test and paste me your output? [08:42] Saviq: use "autopilot list qml_phone_shell" to see cases [08:42] Saviq: and then "autopilot run qml_phone_shell.foo.bar.some.test" to run a single one [08:43] mzanetti, https://pastebin.canonical.com/89233/ [08:43] mzanetti, wait [08:43] ok... after fixing the dir [08:44] Saviq: in qml_phone_shell/tests/__init__.py that is [08:44] mzanetti, yeah, fixed already [08:44] https://pastebin.canonical.com/89234/ [08:46] Saviq: I guess you haven't libautopilot-qt installed [08:46] sil2100: grep-available -FConflicts [08:46] sil2100: sorry, took me some time to find it again ;) [08:46] mzanetti, is already the newest version [08:46] so grep-available -FConflicts [08:46] Saviq: run qml-phone-shell -testability and read the first line of debug output [08:46] mzanetti, and I don't even get the window [08:46] Uh oh, that's so handy! [08:46] Saviq: ah... so it crashes? [08:46] mzanetti, ah, segfault [08:47] hooray! I'm not the only one that has the crash any more! [08:47] didrocks: thanks! [08:47] mzanetti, you never mentioned it was testability's fault ;) [08:47] ... and it doesn't crash under gdb [08:47] Saviq: it's not [08:48] Saviq: yw ;) [08:48] oupss sil2100 ^ [08:48] Saviq: does it crash before or after printing "Loading testability driver" ? [08:48] mzanetti, after [08:48] mzanetti, ah wait [08:48] mzanetti, wrong [08:48] mzanetti, use ./run -- -testability [08:49] mzanetti, I say we need LD_LIBRARY_PATH [08:49] mzanetti, yup [08:50] Saviq: http://wstaw.org/m/2013/04/16/plasma-desktopXx6970.png [08:51] works fine here [08:51] mzanetti, yeah [08:51] mzanetti, ./run has LD_LIBRARY_PATH [08:51] mzanetti, question is why does `make autopilot` work for you;) [08:51] Saviq: it also works fine if I runn it with ../../builddir/qml-phone-shell -testability [08:52] mzanetti, yeah, exactly my point - it shouldn't [08:52] mzanetti, unless you have the unity from phablet-mods installed [08:52] Saviq: hehe... so we found the issue :D [08:52] mzanetti, in which case - you bastard! you're not running Unity :P [08:53] Saviq: did you see the screenshot? [08:53] mzanetti, ;) [08:53] Saviq: unity paints itself in micro-edition here [08:53] Saviq: really unuseable [08:54] Saviq: looking forward to unity next. looks gorgeous @ GRID_UNIT_PX=18 [08:54] mzanetti, but regardless we need a smarter way to determine the binary path [08:54] mzanetti, :) [08:59] Saviq: what concerns me more is that tests fail here but seem to pass in jenkins still [08:59] mzanetti, right [09:03] Saviq: ah no... its just my latest changes that breaks those... and jenkins posted a needs fixing :) [09:03] good jenkins :) [09:07] Saviq: looking at QSortFilterProxyModelQML i am left wondering why the limit and the regular filtering are in the same class and then we do qFatal("QSortFilterProxyModel: filterRegExp and limit are both set which is not supported"); [09:07] Saviq: i think we should split it out into two separate classes [09:07] tsdgeos, tell that to Qt? ;) [09:07] Saviq: tell what? [09:08] that's our class [09:08] tsdgeos, why is that limitation in place anyway? [09:08] tsdgeos, but QSortFilterProxyModel is not, is it? [09:08] sure [09:08] the limitation is artificial imho [09:08] i don't see why we could not implement both [09:09] but again doing the two filterings in the same class seems weird [09:09] if you want both [09:09] you should have a FilterLimit that holds a FilterRegex [09:09] no? [09:09] tsdgeos, but QSortFilterProxyModel does exactly that, no? [09:10] tsdgeos, and doing it in separate objects could have a performance impact [09:10] Saviq: no, filterproxymodel fiilters by a regex [09:10] that's it [09:10] and unpredicted results, if you sort first then filter (or the other way around) [09:10] it doesn't do any "limit" counting [09:11] ah [09:11] it's our class that do the limit implementation [09:12] tsdgeos, you mean that we should have a SortFilterProxyModel that does the sorting and filtering and then a separate limiting one? [09:12] yes [09:12] that seems a more sane separation [09:12] since actually it's what we are already enforcing [09:12] since you can't have a filtering and limiting one [09:12] since it'll crash on you [09:13] and there's almost no shared code anyway [09:13] tsdgeos, yeah, the only thing is [09:13] tsdgeos, performance-wise it's better for just filtering [09:13] tsdgeos, 'cause you don't try and match all of them [09:14] in the SortFilterProxyModel [09:14] just to then limit it to 6 entries [09:14] when sorting, sure, it's the same [09:14] Saviq: what you say would make sense if we supported that use case [09:14] but we don't [09:14] we don't support filter and limiting proxies [09:14] they have a qFatal [09:15] tsdgeos, ah, indeed [09:15] I thought it was about sorting that we did not support it [09:15] nope, it's limit + filter [09:15] so i guess te question is [09:16] do we want to support that usecase or not? [09:16] because at the moment we're not using it :D [09:16] yeah, but we might have worked around it by chaining [09:16] and implementing it may not be that trivial (i guess that's why the qFatal was added) [09:17] and anyway the qFatal will only happen when the filter regexp is set first [09:17] which is not guaranteed by anything else [09:18] right [09:18] my suggestion here would be splitting into two classes [09:18] and if we ever need the combined one for perfomance reasons [09:18] attack that problem when we face it :D [09:19] tsdgeos, is there a reason why we would do that now? other than sanity? ;) [09:19] Saviq: well, i have a task of "reviewing high risk components, sortfilterproxymodel", so i'm reviewing it :D [09:20] tsdgeos, right, but there's nothing we'd gain, is there [09:21] tsdgeos, what I meant there was mostly to verify that dataChanged signals are not emitted spuriously [09:21] well, thing is, the limit code doesn't work that well, actually there's a few FIXMEs in the test that proof it doesn't work [09:21] by splitting it into two i was hoping to make the problem smaller [09:21] and thus easier to target [09:21] tsdgeos, yeah, makes sense [09:21] but i can for sure fix the problem in the current one [09:22] tsdgeos, and if we want to chain them we always can [09:22] and then create a mixed one when we see that we need it [09:24] so, should then i split them or not? :D [09:27] tsdgeos, tsdgeos, yeah, makes sense [09:31] ok :D === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [10:10] jibel: can we trap you for a sec? [10:11] didrocks, trap? [10:11] * jibel runs [10:11] seb128: quick, catch him on the other side! :) [10:11] jibel, haha! [10:11] jibel: we have more autopilot fun on the nvidia machine, it seems we had the screensaver activated [10:11] jibel: we sshed and killed it [10:12] jibel: but nothing seems to move, having someone having a look with the kvm access would be great [10:12] didrocks, okay, looking [10:13] thanks :) [10:13] didrocks, BTW, it seems that jobtimeout option is not working [10:13] jibel: how unsurprising [10:13] job started at 07:37:48 and it is now 10:13:47 [10:14] yep [10:16] didrocks, it is blocked on the HUD with an empty 'type your command' prompt [10:16] ap crash? [10:17] jibel: seems to run looking at the available processes [10:17] jibel: we got as yesterday, the screensaver activated [10:17] so it seems it's a consequence [10:17] like, something hanging up [10:17] and then screensaver on [10:17] yeah, the last warning in .xsession-erros is gnome-session[1457]: WARNING: Detected that screensaver has left the bus [10:18] jibel: we killed it [10:18] jibel: but it didn't restart even with this [10:18] didrocks, and the last command excuted by AP is 08:26:03.368 DEBUG _X11:311 - Moving mouse to position 640,512 without animation. [10:18] 2hours ago [10:18] jibel: how do you see it? result.xml is empty? [10:18] unity-result.xml [10:19] didrocks, /home/jenkins/results/artifacts/ap_test_debug_log.txt [10:20] jibel: so your guess is that "08:26:03.365 WARNING __init__:97 - Test left the hud open, closing it..." didn't close it? [10:20] didrocks, yep [10:20] dednick, hi [10:20] do we have a video recording for that? [10:20] dednick, did you try importing Unity 0.1? [10:20] didrocks, or AP likes the sunny weather too, started the screensaver and went to the beach [10:20] dednick, to me it complains with something weird [10:21] file:///home/cimi/Development/unity/phablet.fake-unity-plugin/Dash/LensView.qml:18:1: module "Utils" is not installed [10:21] import Utils 0.1 [10:21] jibel, didrocks: those in the log are weird [10:21] 08:25:28.506 ERROR proxies:410 - Introspect error on :1.23:/com/canonical/Unity/Debug: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [10:21] jibel: I hope it will burn in fire :) [10:21] seb128: is it the same test? [10:21] yeah, seems so [10:21] didrocks, it's just before in the log [10:21] unity.tests.test_dash.PreviewInvocationTests.test_preview_key.ogv [10:22] 08:13:02.767 DEBUG testcase:141 [10:22] seb128, unity.tests.test_dash.PreviewInvocationTests.test_preview_key.ogv is the recording of the test [10:22] that's still ongoing [10:22] yeah, I think we won't have the video :/ [10:23] I wonder if the traceback on the previous test is what caused this [10:23] no attribute hud? [10:23] yep [10:24] nope… [10:24] veebers: ping? (any chance you still here?) [10:24] still something to fix though. sil2100 ^ [10:24] sil2100: on some tests: [10:24] AttributeError: 'PanelWindowButtonsTests' object has no attribute 'hud' [10:24] and AttributeError: 'SwitcherTests' object has no attribute 'hud' [10:25] sil2100: do you mind having a look at fixing it? [10:25] didrocks: oh, ok, is that in raring? [10:25] /usr/lib/python2.7/dist-packages/unity/tests/__init__.py (line 98) [10:25] sil2100: right [10:25] didrocks: on it, will just move out of the balcony since I see shit [10:25] sil2100: ok :) [10:25] still doesn't explain why all the Debug doesn't work suddenly… [10:26] we really need autopilot guys I guess… [10:26] didrocks, seb128 the video shows the HUD, open with the prompt and a mouse pointer stuck in the middle of the screen for 9min54s [10:26] ok, so then the screensaver quicks in… [10:26] Is it on the generic job? [10:27] sil2100: it's in a ssh session, let me paste you it [10:27] Cimi: you may need to add plugins to the import path. [10:27] dednick, but why Utils?? [10:28] because the LensView.qml imports Utils. [10:28] dednick, ah indeed good point [10:28] :) [10:28] sil2100: http://paste.ubuntu.com/5712807/ [10:28] sil2100: the 3 errors are pasted here [10:28] Thanks [10:28] didrocks, can I close the log? [10:29] seb128: yep [10:29] didrocks, at least dbus commands seem to still work/get a reply [10:29] oh right, I didn't read was LensView :) [10:29] Cimi: I think you will probably have to do it ordered after the test/qml import though. Otherwise it might load Unity plugin from the plugins folder. [10:29] was looking at tst_LensView [10:30] didrocks, FYI bug 1169510 [10:30] bug 1169510 in UTAH "UTAH doesn't honor jobtimeout" [Undecided,New] https://launchpad.net/bugs/1169510 [10:30] jibel: thanks! adding to my list :) [10:31] didrocks: it just fails on those tests or on all? [10:33] sil2100: those are the 3 I can spot on [10:33] I see what's wrong, hmmm [10:33] sil2100: it's weird, it didn't fail yesterday though: http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/68/label=autopilot-nvidia/artifact/results/artifacts/ap_test_debug_log.txt [10:33] How is it possible we didn't notice it before? [10:34] It's REALLY wierd [10:34] sil2100: does it make sense it's failing? [10:34] or can it be a side effect of something failing? [10:34] AH! [10:34] I know [10:34] Well, ok, I figured out part of the problem at least [10:35] sil2100: do you mind sharing? It's maybe due to everything being stuck after that [10:35] Fixed the hud AttributeError: 'PanelWindowButtonsTests' object has no attribute 'hud' thingy, now we need to check why the test left the HUD open [10:35] dednick, still issues [10:36] dednick, now it can't find unity-qml [10:36] *utils-qml [10:36] I have a branch for that, but anyway still need to figure out why the HUD is left open - do you have a vid for this one? [10:36] Cimi: what's your command line? [10:37] Preparing a merge for that AttributeError [10:37] dednick, error file:///home/cimi/Development/unity/phablet.fake-unity-plugin/Dash/LensView.qml:18:1: module "Utils" plugin "Utils-qml" not found [10:37] import Utils 0.1 [10:37] dednick, import [10:37] add_qml_test(LensView IMPORT_PATHS ${CMAKE_SOURCE_DIR}/plugins ${CMAKE_CURRENT_BINARY_DIR}/qml) [10:38] sil2100: but, do you know why we didn't see it in yesterday's run btw? [10:38] if I invert the lines, it fails to import unity [10:39] didrocks: the AttributeError error you mean? It seems that yesterday the tests didn't break mysteriously and didn't leave the HUD open - it seems no test left the HUD opened since a long time [10:40] sil2100: right, so if it was a real AttributeError [10:40] we would have see it, right? [10:41] didrocks: it's like this... there was a migration from the notation of self.emulator to self.unity.emulator (i.e. self.hud -> self.unity.hud), and someone didn't change that for the cleanup routines for HUD, so the AttributeError was because of this (and I fixed it now) - still, we need to know why the test left the HUD opened, which I'm still testing here [10:42] Cimi: you're using source folder. [10:42] plugin binary is in builddir [10:42] sil2100: and we need to understand why we didn't have the issue yesterday… [10:42] dednick, damn indeed [10:42] dednick, thanks mate [10:42] * Cimi tries [10:42] sil2100, from what you describe the error should always be there? [10:42] Cimi: no prob [10:43] sil2100, or is it in a fallback/error codepath? [10:43] seb128: yes, it's in a fallback codepath [10:43] seb128: it is executed only when the HUD is left open [10:43] And till now it never happened before, so we didn't see it [10:43] https://code.launchpad.net/~sil2100/unity/autopilot_leftover_in_hud_cleanup/+merge/159121 [10:44] sil2100, oh, so with your fix the hud will be forced closed? [10:44] seb128, didrocks: do we have vids of those failures didrocks just pasted? [10:44] Cimi: use ${CMAKE_BINARY_DIR}/plugins [10:44] sil2100, jibel had one he was looking at [10:45] dednick, I used ${CMAKE_SOURCE_DIR}/builddir/plugins [10:45] so it turns out sound menu play/pause button regressed [10:45] seb128: in AP it's like this: when a test finishes and AP notices that one of the elements is left opened (like hud or the dash) it tries to close it by himself and informs the user about it [10:45] changed now though [10:45] om26er, bug number? [10:46] seb128: I just fixed it that it now closes it correctly instead of dying with AttributeError [10:46] Ah, hmmm [10:46] sil2100, ok, still a bug that it's left open [10:46] seb128: yes, that's why a vid would be nice, or maybe the whole ap_test_debug_log.txt [10:47] jibel: ^ [10:47] ? [10:47] didrocks, sorry for bothering you, you know always everything :) since I upgraded to raring, I have to restart every time I plugin an external monitor when running unity, because the screen gets heavily corrupted and there's no way to get it back unless a restart of X, is there a known bug I can subscribe? [10:47] sil2100: yeah, jibel has the video, not sure how he got it as recordmydesktop was still opened [10:47] sil2100: https://code.launchpad.net/~sil2100/cupstream2distro-config/stack_package_dependency_additions/+merge/159110, commented btw ;) [10:47] seb128, not yet reported, just discovered that. I will report that in a few minutes [10:47] didrocks: thanks! Will read in a moment :8 [10:48] Cimi: there is a bug about it for some people, popey opened it. popey, do you have the bug # handy? ^ [10:48] oh blimey, yes [10:49] bug 1157114 [10:49] bug 1157114 in compiz (Ubuntu) "corruption making desktop unusable after docking/undocking" [Undecided,Confirmed] https://launchpad.net/bugs/1157114 [10:49] here you go Cimi ^ [10:49] thanks popey :) [10:49] np [10:49] thanks popey ! [10:50] yw [10:50] Ah crap, didn't check where gstreamer-ffmpeg is from [10:51] sil2100, http://people.canonical.com/~j-lallement/unity.tests.test_dash.PreviewInvocationTests.test_preview_key.ogv [10:51] sil2100: basically ffmpeg == danger ;) [10:51] didrocks: do we have a replacement for systray whitelists in raring? [10:52] or is the answer "fix the app" ? [10:52] popey: the second one [10:52] balls [10:52] popey: it's a design decision [10:52] thanks [10:52] yw ;) [10:53] * popey discovers bug 974480 [10:53] bug 974480 in Ayatana Design "Notification area whitelist is obsolete" [High,Fix committed] https://launchpad.net/bugs/974480 [10:53] jibel: thanks! [10:54] jibel: jenkins autopilot always returns a ap_test_debug_log.txt with all the tests output... is it possible to get one for this run? [10:55] Since it looks to me that most of those tests failed just because some other test left the HUD opened and no one closed it [10:55] So we need to backtrace it [10:57] sil2100, http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/76/label=autopilot-nvidia/artifact/results/artifacts/ [10:58] or wait for the publication to jenkins.qa.u.c [10:58] Oh, thanks! Didn't know it's on the generic job [11:00] didrocks, sil2100 so, when you want to stop a job cleanly, ssh to the machine running the tests you want to stop and run: touch /home/jenkins/.ap_tests_finished [11:00] wow earthquake [11:01] jibel: thanks for the tip! [11:02] Good to know! [11:06] anyone having trouble with the latest phablet build script? [11:09] for running on device that is [11:11] dednick: I didn't have so yesterday... but let me try today [11:11] mzanetti: i'm doing it from a clean flash. didnt install software-properties-common :( [11:12] so no add-apt-repository === MacSlow is now known as MacSlow|lunch [11:13] dednick: while ./run_on_device -s ? [11:15] mzanetti: run_on_device "seems" like it works, but then do ./run_on_device and wont make on device. "cmake" not installed [11:15] trying again [11:15] dednick: you did run it with -s, right? [11:15] mzanetti: ya [11:15] first with, then without [11:16]