[04:50] <slangasek> smspillaz: in and out :)
[04:51] <smspillaz> slangasek: coolio. I replied to your merge review and uploaded a revised version
[04:51] <smspillaz> s/your/my/
[04:51] <smspillaz> (that you were reviewing)
[04:54] <slangasek> smspillaz: cool; I probably won't have a chance to take a look tonight, but will take another gander tomorrow
[04:55] <smspillaz> no problem.
[04:55] <smspillaz> there's one more EXPECT_EQ missing, I'll keep looking for it
[07:18] <didrocks> sil2100: hey, how are you?
[07:42] <sil2100> didrocks: hi! More or less good, how about you?
[07:42] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_disable_screen_lock/+merge/158989 <- can anyone re-review?
[07:42] <didrocks> sil2100: I'm ok, thanks
[07:43] <didrocks> sil2100: did you talk with thomi? mayb e francis should have a look? not sure who else
[07:43] <didrocks> sil2100: the gsettings part is fine
[07:43] <didrocks> sil2100: not sure about the autopilot part
[07:44] <didrocks> sil2100: commented with what I told above ^
[07:44] <didrocks> 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] <sil2100> 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] <didrocks> sil2100: and on the #1 issue, which was about the stacks and so on?
[07:52] <didrocks> sil2100: ? ^
[07:53] <sil2100> didrocks: ah, sorry, had a few discussions just now
[07:53] <sil2100> didrocks: so, in overall:
[07:56] <sil2100> 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] <sil2100> 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] <didrocks> sil2100: ok, can you list that somewhere and maybe add the depends we really need for sure (apart from mysql)
[07:57] <didrocks> sil2100: maybe Mirv can look at the mysql part? ^
[07:57] <didrocks> so that you can advance on the rest
[07:57] <sil2100> didrocks: I have it on my branch, waiting for Mirv to comment
[07:57] <didrocks> ok
[08:00] <sil2100> 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] <sil2100> Shouldn't libqt5sql5-sqlite be sufficient for him?
[08:02] <didrocks> sil2100: yeah, but it's picking the first of the list if nothing is installed before
[08:02] <didrocks> sil2100: so if the requirement of libqt5sql5 is before something pulling libqt5sql5-sqlite, it will take the mysql one
[08:03] <didrocks> sil2100: actually, I think on that list, libqt5sql5-sqlite should be first
[08:03] <sil2100> didrocks: yes, that's what just popped in my head now as well
[08:03] <didrocks> then, if someone wants another sql, he needs to explicitely specify it
[08:03] <didrocks> it's like, "the lighter first"
[08:03] <didrocks> Mirv: there are some qt5 package in the ppa, mind making this change? ^
[08:03] <sil2100> 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] <didrocks> or sil2100 ^
[08:04] <sil2100> Since I've been wondering if that works like this
[08:04] <didrocks> sil2100: hum, if it's first, right, but I would anyway fix the dep order as well
[08:04] <didrocks> the recommends* order rather
[08:04] <sil2100> Right
[08:04] <sil2100> Mirv: ^ (poked here and everywhere)
[08:05] <Mirv> I think it's alright as discussed #elsewhere :)
[08:06] <Mirv> sqlite is probably the best first option
[08:07] <didrocks> 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] <Mirv> sil2100: I can indeed fetch your debdiff, apply and upload
[08:10] <didrocks> Mirv: you need to do the same in the ubuntu-unity/daily-build-next ppa as well I guess as I told
[08:10] <didrocks> Mirv: I think mterry uploaded there a difference version of qt5
[08:11] <Saviq> mzanetti, did you try and run the autopilot tests locally recently? after having fixed the path, it seems hang
[08:11] <Saviq> +to
[08:11] <Saviq> mterry had the same
[08:12] <Mirv> didrocks: ah, so it seems, I hadn't heard anything about that
[08:12] <Mirv> also, I've now 5.0.2 packaging but I'll have a separate 5.0.1 one
[08:13] <sil2100> didrocks: I think I'm not part of the team ;)
[08:16] <Mirv> hmm, mterry doesn't seem to have his packaging changes in any bzr
[08:17] <sil2100> Yes, that's why I fetched the sources from the PPA...
[08:17] <didrocks> Mirv: do you mind checking up with him and resync all this if needed?
[08:18] <Mirv> 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] <Mirv> and surely also chat a bit when he wakes up
[08:21] <sil2100> Mirv: should I send you the debdiff?
[08:22] <Mirv> sil2100: yes if you had something on top of 5.0.1+dfsg-0ubuntu5~xembed3, but no otherwise
[08:23] <sil2100> I could push the modified qt package to the next PPA, but it seems I have no permissions
[08:23] <Mirv> I can change the sql order anyhow
[08:23] <sil2100> Mirv: right, it's a trivial change anyway
[08:28] <mzanetti> Saviq: by running "make autopilot" you mean?
[08:29] <Saviq> mzanetti, actually by going "autopilot run ...."
[08:29] <Saviq> mzanetti, but yeah, make autopilot fails due to a wrong path
[08:29] <mzanetti> Saviq: yeah... they broke when forbidding in-source builds
[08:31] <Saviq> mzanetti, but that's easily fixed, the fact that it hangs is a bit more troubling
[08:32] <mzanetti> Saviq: does it hang forever? I think autopilot has a timeout and gives up
[08:32] <Saviq> mzanetti, well yeah, it gives up
[08:33] <mzanetti> Saviq: ah... after fixing the path they hang... I see
[08:33] <Saviq> yup
[08:33] <mzanetti> 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] <sil2100> didrocks: btw. is there a nice command that could tell me which package 'conflict' with a given package?
[08:36] <mzanetti> Saviq: hmm... they don't hang here... they do fail tho
[08:36] <Saviq> mzanetti, what's your res?
[08:36]  * mzanetti wonders why they pass in jenkins
[08:37] <mzanetti> Saviq: 2880x1800
[08:37] <Saviq> mzanetti, yeah, that might be why it hangs here, I'm at a humble 1600x900
[08:37] <Saviq> jeez dude
[08:38] <mzanetti> yeah..... and then there are people wanting me to force to use only 80 cols in my text editor
[08:38] <mzanetti> thats smaller than the panel
[08:38] <mzanetti> :D
[08:39] <mzanetti> Saviq: still... it shouldn't hang because of the resolution
[08:39] <Saviq> rotfl
[08:41] <mzanetti> Saviq: can you please just run 1 autopilot test and paste me your output?
[08:42] <mzanetti> Saviq: use "autopilot list qml_phone_shell" to see cases
[08:42] <mzanetti> Saviq: and then "autopilot run qml_phone_shell.foo.bar.some.test" to run a single one
[08:43] <Saviq> mzanetti, https://pastebin.canonical.com/89233/
[08:43] <Saviq> mzanetti, wait
[08:43] <mzanetti> ok... after fixing the dir
[08:44] <mzanetti> Saviq: in qml_phone_shell/tests/__init__.py that is
[08:44] <Saviq> mzanetti, yeah, fixed already
[08:44] <Saviq> https://pastebin.canonical.com/89234/
[08:46] <mzanetti> Saviq: I guess you haven't libautopilot-qt installed
[08:46] <didrocks> sil2100: grep-available -FConflicts <expression>
[08:46] <didrocks> sil2100: sorry, took me some time to find it again ;)
[08:46] <Saviq> mzanetti, is already the newest version
[08:46] <didrocks> so grep-available -FConflicts <package_name>
[08:46] <mzanetti> Saviq: run qml-phone-shell -testability and read the first line of debug output
[08:46] <Saviq> mzanetti, and I don't even get the window
[08:46] <sil2100> Uh oh, that's so handy!
[08:46] <mzanetti> Saviq: ah... so it crashes?
[08:46] <Saviq> mzanetti, ah, segfault
[08:47] <mzanetti> hooray! I'm not the only one that has the crash any more!
[08:47] <sil2100> didrocks: thanks!
[08:47] <Saviq> mzanetti, you never mentioned it was testability's fault ;)
[08:47] <Saviq> ... and it doesn't crash under gdb
[08:47] <mzanetti> Saviq: it's not
[08:48] <didrocks> Saviq: yw ;)
[08:48] <didrocks> oupss sil2100 ^
[08:48] <mzanetti> Saviq: does it crash before or after printing "Loading testability driver" ?
[08:48] <Saviq> mzanetti, after
[08:48] <Saviq> mzanetti, ah wait
[08:48] <Saviq> mzanetti, wrong
[08:48] <Saviq> mzanetti, use ./run -- -testability
[08:49] <Saviq> mzanetti, I say we need LD_LIBRARY_PATH
[08:49] <Saviq> mzanetti, yup
[08:50] <mzanetti> Saviq: http://wstaw.org/m/2013/04/16/plasma-desktopXx6970.png
[08:51] <mzanetti> works fine here
[08:51] <Saviq> mzanetti, yeah
[08:51] <Saviq> mzanetti, ./run has LD_LIBRARY_PATH
[08:51] <Saviq> mzanetti, question is why does `make autopilot` work for you;)
[08:51] <mzanetti> Saviq: it also works fine if I runn it with ../../builddir/qml-phone-shell -testability
[08:52] <Saviq> mzanetti, yeah, exactly my point - it shouldn't
[08:52] <Saviq> mzanetti, unless you have the unity from phablet-mods installed
[08:52] <mzanetti> Saviq: hehe... so we found the issue :D
[08:52] <Saviq> mzanetti, in which case - you bastard! you're not running Unity :P
[08:53] <mzanetti> Saviq: did you see the screenshot?
[08:53] <Saviq> mzanetti, ;)
[08:53] <mzanetti> Saviq: unity paints itself in micro-edition here
[08:53] <mzanetti> Saviq: really unuseable
[08:54] <mzanetti> Saviq: looking forward to unity next. looks gorgeous @ GRID_UNIT_PX=18
[08:54] <Saviq> mzanetti, but regardless we need a smarter way to determine the binary path
[08:54] <Saviq> mzanetti, :)
[08:59] <mzanetti> Saviq: what concerns me more is that tests fail here but seem to pass in jenkins still
[08:59] <Saviq> mzanetti, right
[09:03] <mzanetti> Saviq: ah no... its just my latest changes that breaks those... and jenkins posted a needs fixing :)
[09:03] <mzanetti> good jenkins :)
[09:07] <tsdgeos> 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] <tsdgeos> Saviq: i think we should split it out into two separate classes
[09:07] <Saviq> tsdgeos, tell that to Qt? ;)
[09:07] <tsdgeos> Saviq: tell what?
[09:08] <tsdgeos> that's our class
[09:08] <Saviq> tsdgeos, why is that limitation in place anyway?
[09:08] <Saviq> tsdgeos, but QSortFilterProxyModel is not, is it?
[09:08] <tsdgeos> sure
[09:08] <tsdgeos> the limitation is artificial imho
[09:08] <tsdgeos> i don't see why we could not implement both
[09:09] <tsdgeos> but again doing the two filterings in the same class seems weird
[09:09] <tsdgeos> if you want both
[09:09] <tsdgeos> you should have a FilterLimit that holds a FilterRegex
[09:09] <tsdgeos> no?
[09:09] <Saviq> tsdgeos, but QSortFilterProxyModel does exactly that, no?
[09:10] <Saviq> tsdgeos, and doing it in separate objects could have a performance impact
[09:10] <tsdgeos> Saviq: no, filterproxymodel fiilters by a regex
[09:10] <tsdgeos> that's it
[09:10] <Saviq> and unpredicted results, if you sort first then filter (or the other way around)
[09:10] <tsdgeos> it doesn't do any "limit" counting
[09:11] <Saviq> ah
[09:11] <tsdgeos> it's our class that do the limit implementation
[09:12] <Saviq> tsdgeos, you mean that we should have a SortFilterProxyModel that does the sorting and filtering and then a separate limiting one?
[09:12] <tsdgeos> yes
[09:12] <tsdgeos> that seems a more sane separation
[09:12] <tsdgeos> since actually it's what we are already enforcing
[09:12] <tsdgeos> since you can't have a filtering and limiting one
[09:12] <tsdgeos> since it'll crash on you
[09:13] <tsdgeos> and there's almost no shared code anyway
[09:13] <Saviq> tsdgeos, yeah, the only thing is
[09:13] <Saviq> tsdgeos, performance-wise it's better for just filtering
[09:13] <Saviq> tsdgeos, 'cause you don't try and match all of them
[09:14] <Saviq> in the SortFilterProxyModel
[09:14] <Saviq> just to then limit it to 6 entries
[09:14] <Saviq> when sorting, sure, it's the same
[09:14] <tsdgeos> Saviq: what you say would make sense if we supported that use case
[09:14] <tsdgeos> but we don't
[09:14] <tsdgeos> we don't support filter and limiting proxies
[09:14] <tsdgeos> they have a qFatal
[09:15] <Saviq> tsdgeos, ah, indeed
[09:15] <Saviq> I thought it was about sorting that we did not support it
[09:15] <tsdgeos> nope, it's limit + filter
[09:15] <tsdgeos> so i guess te question is
[09:16] <tsdgeos> do we want to support that usecase or not?
[09:16] <tsdgeos> because at the moment we're not using it :D
[09:16] <Saviq> yeah, but we might have worked around it by chaining
[09:16] <tsdgeos> and implementing it may not be that trivial (i guess that's why the qFatal was added)
[09:17] <Saviq> and anyway the qFatal will only happen when the filter regexp is set first
[09:17] <Saviq> which is not guaranteed by anything else
[09:18] <tsdgeos> right
[09:18] <tsdgeos> my suggestion here would be splitting into two classes
[09:18] <tsdgeos> and if we ever need the combined one for perfomance reasons
[09:18] <tsdgeos> attack that problem when we face it :D
[09:19] <Saviq> tsdgeos, is there a reason why we would do that now? other than sanity? ;)
[09:19] <tsdgeos> Saviq: well, i have a task of "reviewing high risk components, sortfilterproxymodel", so i'm reviewing it :D
[09:20] <Saviq> tsdgeos, right, but there's nothing we'd gain, is there
[09:21] <Saviq> tsdgeos, what I meant there was mostly to verify that dataChanged signals are not emitted spuriously
[09:21] <tsdgeos> 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] <tsdgeos> by splitting it into two i was hoping to make the problem smaller
[09:21] <tsdgeos> and thus easier to target
[09:21] <Saviq> tsdgeos, yeah, makes sense
[09:21] <tsdgeos> but i can for sure fix the problem in the current one
[09:22] <Saviq> tsdgeos, and if we want to chain them we always can
[09:22] <Saviq> and then create a mixed one when we see that we need it
[09:24] <tsdgeos> so, should then i split them or not? :D
[09:27] <Saviq> tsdgeos, <Saviq> tsdgeos, yeah, makes sense
[09:31] <tsdgeos> ok :D
[10:10] <didrocks> jibel: can we trap you for a sec?
[10:11] <jibel> didrocks, trap?
[10:11]  * jibel runs
[10:11] <didrocks> seb128: quick, catch him on the other side! :)
[10:11] <seb128> jibel, haha!
[10:11] <didrocks> jibel: we have more autopilot fun on the nvidia machine, it seems we had the screensaver activated
[10:11] <didrocks> jibel: we sshed and killed it
[10:12] <didrocks> jibel: but nothing seems to move, having someone having a look with the kvm access would be great
[10:12] <jibel> didrocks, okay, looking
[10:13] <didrocks> thanks :)
[10:13] <jibel> didrocks, BTW, it seems that jobtimeout option is not working
[10:13] <didrocks> jibel: how unsurprising
[10:13] <jibel> job started at 07:37:48 and it is now 10:13:47
[10:14] <didrocks> yep
[10:16] <jibel> didrocks, it is blocked on the HUD with an empty 'type your command' prompt
[10:16] <jibel> ap crash?
[10:17] <didrocks> jibel: seems to run looking at the available processes
[10:17] <didrocks> jibel: we got as yesterday, the screensaver activated
[10:17] <didrocks> so it seems it's a consequence
[10:17] <didrocks> like, something hanging up
[10:17] <didrocks> and then screensaver on
[10:17] <jibel> yeah, the last warning in .xsession-erros is gnome-session[1457]: WARNING: Detected that screensaver has left the bus
[10:18] <didrocks> jibel: we killed it
[10:18] <didrocks> jibel: but it didn't restart even with this
[10:18] <jibel> 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] <jibel> 2hours ago
[10:18] <didrocks> jibel: how do you see it? result.xml is empty?
[10:18] <didrocks> unity-result.xml
[10:19] <jibel> didrocks, /home/jenkins/results/artifacts/ap_test_debug_log.txt
[10:20] <didrocks> 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] <jibel> didrocks, yep
[10:20] <Cimi> dednick, hi
[10:20] <seb128> do we have a video recording for that?
[10:20] <Cimi> dednick, did you try importing Unity 0.1?
[10:20] <jibel> didrocks, or AP likes the sunny weather too, started the screensaver and went to the beach
[10:20] <Cimi> dednick, to me it complains with something weird
[10:21] <Cimi> file:///home/cimi/Development/unity/phablet.fake-unity-plugin/Dash/LensView.qml:18:1: module "Utils" is not installed
[10:21] <Cimi>      import Utils 0.1
[10:21] <seb128> jibel, didrocks: those in the log are weird
[10:21] <seb128> 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] <didrocks> jibel: I hope it will burn in fire :)
[10:21] <didrocks> seb128: is it the same test?
[10:21] <didrocks> yeah, seems so
[10:21] <seb128> didrocks, it's just before in the log
[10:21] <didrocks> unity.tests.test_dash.PreviewInvocationTests.test_preview_key.ogv
[10:22] <didrocks> 08:13:02.767 DEBUG testcase:141
[10:22] <jibel> seb128, unity.tests.test_dash.PreviewInvocationTests.test_preview_key.ogv is the recording of the test
[10:22] <seb128> that's still ongoing
[10:22] <didrocks> yeah, I think we won't have the video :/
[10:23] <didrocks> I wonder if the traceback on the previous test is what caused this
[10:23] <seb128> no attribute hud?
[10:23] <didrocks> yep
[10:24] <didrocks> nope…
[10:24] <sil2100> veebers: ping? (any chance you still here?)
[10:24] <didrocks> still something to fix though. sil2100 ^
[10:24] <didrocks> sil2100: on some tests:
[10:24] <didrocks> AttributeError: 'PanelWindowButtonsTests' object has no attribute 'hud'
[10:24] <didrocks> and AttributeError: 'SwitcherTests' object has no attribute 'hud'
[10:25] <didrocks> sil2100: do you mind having a look at fixing it?
[10:25] <sil2100> didrocks: oh, ok, is that in raring?
[10:25] <didrocks> /usr/lib/python2.7/dist-packages/unity/tests/__init__.py (line 98)
[10:25] <didrocks> sil2100: right
[10:25] <sil2100> didrocks: on it, will just move out of the balcony since I see shit
[10:25] <didrocks> sil2100: ok :)
[10:25] <didrocks> still doesn't explain why all the Debug doesn't work suddenly…
[10:26] <didrocks> we really need autopilot guys I guess…
[10:26] <jibel> 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] <didrocks> ok, so then the screensaver quicks in…
[10:26] <sil2100> Is it on the generic job?
[10:27] <didrocks> sil2100: it's in a ssh session, let me paste you it
[10:27] <dednick> Cimi: you may need to add plugins to the import path.
[10:27] <Cimi> dednick, but why Utils??
[10:28] <dednick> because the LensView.qml imports Utils.
[10:28] <Cimi> dednick, ah indeed good point
[10:28] <dednick> :)
[10:28] <didrocks> sil2100: http://paste.ubuntu.com/5712807/
[10:28] <didrocks> sil2100: the 3 errors are pasted here
[10:28] <sil2100> Thanks
[10:28] <seb128> didrocks, can I close the log?
[10:29] <didrocks> seb128: yep
[10:29] <seb128> didrocks, at least dbus commands seem to still work/get a reply
[10:29] <Cimi> oh right, I didn't read was LensView :)
[10:29] <dednick> 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] <Cimi> was looking at tst_LensView
[10:30] <jibel> didrocks, FYI bug 1169510
[10:30] <didrocks> jibel: thanks! adding to my list :)
[10:31] <sil2100> didrocks: it just fails on those tests or on all?
[10:33] <didrocks> sil2100: those are the 3 I can spot on
[10:33] <sil2100> I see what's wrong, hmmm
[10:33] <didrocks> sil2100: it's weird, it didn't fail yesterday though: http://<IP_ADDRESS>:8080/job/ps-generic-autopilot-release-testing/68/label=autopilot-nvidia/artifact/results/artifacts/ap_test_debug_log.txt
[10:33] <sil2100> How is it possible we didn't notice it before?
[10:34] <sil2100> It's REALLY wierd
[10:34] <didrocks> sil2100: does it make sense it's failing?
[10:34] <didrocks> or can it be a side effect of something failing?
[10:34] <sil2100> AH!
[10:34] <sil2100> I know
[10:34] <sil2100> Well, ok, I figured out part of the problem at least
[10:35] <didrocks> sil2100: do you mind sharing? It's maybe due to everything being stuck after that
[10:35] <sil2100> 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] <Cimi> dednick, still issues
[10:36] <Cimi> dednick, now it can't find unity-qml
[10:36] <Cimi> *utils-qml
[10:36] <sil2100> 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] <dednick> Cimi: what's your command line?
[10:37] <sil2100> Preparing a merge for that AttributeError
[10:37] <Cimi> 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] <Cimi>      import Utils 0.1
[10:37] <Cimi> dednick, import
[10:37] <Cimi> add_qml_test(LensView IMPORT_PATHS ${CMAKE_SOURCE_DIR}/plugins ${CMAKE_CURRENT_BINARY_DIR}/qml)
[10:38] <didrocks> sil2100: but, do you know why we didn't see it in yesterday's run btw?
[10:38] <Cimi> if I invert the lines, it fails to import unity
[10:39] <sil2100> 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] <didrocks> sil2100: right, so if it was a real AttributeError
[10:40] <didrocks> we would have see it, right?
[10:41] <sil2100> 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] <dednick> Cimi: you're using source folder.
[10:42] <dednick> plugin binary is in builddir
[10:42] <didrocks> sil2100: and we need to understand why we didn't have the issue yesterday…
[10:42] <Cimi> dednick, damn indeed
[10:42] <Cimi> dednick, thanks mate
[10:42]  * Cimi tries
[10:42] <seb128> sil2100, from what you describe the error should always be there?
[10:42] <dednick> Cimi: no prob
[10:43] <seb128> sil2100, or is it in a fallback/error codepath?
[10:43] <sil2100> seb128: yes, it's in a fallback codepath
[10:43] <sil2100> seb128: it is executed only when the HUD is left open
[10:43] <sil2100> And till now it never happened before, so we didn't see it
[10:43] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_leftover_in_hud_cleanup/+merge/159121
[10:44] <seb128> sil2100, oh, so with your fix the hud will be forced closed?
[10:44] <sil2100> seb128, didrocks: do we have vids of those failures didrocks just pasted?
[10:44] <dednick> Cimi: use ${CMAKE_BINARY_DIR}/plugins
[10:44] <seb128> sil2100, jibel had one he was looking at
[10:45] <Cimi> dednick, I used ${CMAKE_SOURCE_DIR}/builddir/plugins
[10:45] <om26er> so it turns out sound menu play/pause button regressed
[10:45] <sil2100> 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] <Cimi> changed now though
[10:45] <seb128> om26er, bug number?
[10:46] <sil2100> seb128: I just fixed it that it now closes it correctly instead of dying with AttributeError
[10:46] <sil2100> Ah, hmmm
[10:46] <seb128> sil2100, ok, still a bug that it's left open
[10:46] <sil2100> seb128: yes, that's why a vid would be nice, or maybe the whole ap_test_debug_log.txt
[10:47] <sil2100> jibel: ^
[10:47] <sil2100> ?
[10:47] <Cimi> 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] <didrocks> sil2100: yeah, jibel has the video, not sure how he got it as recordmydesktop was still opened
[10:47] <didrocks> sil2100: https://code.launchpad.net/~sil2100/cupstream2distro-config/stack_package_dependency_additions/+merge/159110, commented btw ;)
[10:47] <om26er> seb128, not yet reported, just discovered that. I will report that in a few minutes
[10:47] <sil2100> didrocks: thanks! Will read in a moment :8
[10:48] <didrocks> Cimi: there is a bug about it for some people, popey opened it. popey, do you have the bug # handy? ^
[10:48] <popey> oh blimey, yes
[10:49] <popey> bug 1157114
[10:49] <didrocks> here you go Cimi ^
[10:49] <didrocks> thanks popey :)
[10:49] <popey> np
[10:49] <Cimi> thanks popey !
[10:50] <popey> yw
[10:50] <sil2100> Ah crap, didn't check where gstreamer-ffmpeg is from
[10:51] <jibel> sil2100, http://people.canonical.com/~j-lallement/unity.tests.test_dash.PreviewInvocationTests.test_preview_key.ogv
[10:51] <didrocks> sil2100: basically ffmpeg == danger ;)
[10:51] <popey> didrocks: do we have a replacement for systray whitelists in raring?
[10:52] <popey> or is the answer "fix the app" ?
[10:52] <didrocks> popey: the second one
[10:52] <popey> balls
[10:52] <didrocks> popey: it's a design decision
[10:52] <popey> thanks
[10:52] <didrocks> yw ;)
[10:53]  * popey discovers bug 974480
[10:53] <sil2100> jibel: thanks!
[10:54] <sil2100> 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] <sil2100> 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] <sil2100> So we need to backtrace it
[10:57] <jibel> sil2100, http://<IP_ADDRESS>:8080/job/ps-generic-autopilot-release-testing/76/label=autopilot-nvidia/artifact/results/artifacts/
[10:58] <jibel> or wait for the publication to jenkins.qa.u.c
[10:58] <sil2100> Oh, thanks! Didn't know it's on the generic job
[11:00] <jibel> 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] <om26er> wow earthquake
[11:01] <didrocks> jibel: thanks for the tip!
[11:02] <sil2100> Good to know!
[11:06] <dednick> anyone having trouble with the latest phablet build script?
[11:09] <dednick> for running on device that is
[11:11] <mzanetti> dednick: I didn't have so yesterday... but let me try today
[11:11] <dednick> mzanetti: i'm doing it from a clean flash. didnt install software-properties-common :(
[11:12] <dednick> so no add-apt-repository
[11:13] <mzanetti> dednick: while ./run_on_device -s ?
[11:15] <dednick> mzanetti: run_on_device "seems" like it works, but then do ./run_on_device and wont make on device. "cmake" not installed
[11:15] <dednick> trying again
[11:15] <mzanetti> dednick: you did run it with -s, right?
[11:15] <dednick> mzanetti: ya
[11:15] <dednick> first with, then without
[11:16] <mzanetti> works for me... but I flashed yesterday and did the -s yesterday too
[11:16] <dednick> and connected to wireless
[11:16] <mzanetti> I'll do a clean flash in the background and let you know
[11:21] <dednick> hm. the device seems to randomly kill my ssh connection.
[11:27] <sil2100> Ah
[11:27] <sil2100> Interesting
[11:33] <dednick> mzanetti: i think my connection must have been killed during the setup last time. seems to be working now.
[11:34] <dednick> (even though i tried the setup multiple times)
[11:47] <Saviq> dandrader, hey, so with your patch all apps get launched in the side stage, which is not the case without the patch
[11:48] <Cimi> I have this LensView test https://code.launchpad.net/~unity-team/unity/phablet.test_LensView/+merge/159134
[11:48] <Cimi> Categories in the Unity fake plugin are not implemented, so it complains (warning) but they are not meant to be tested in LensView, shall I add them as well now?
[11:49] <dandrader> Saviq, hmmm. camera goes to the main stage
[11:50] <dandrader> Saviq, although you just see a black rectangle
[11:50] <Saviq> dandrader, right, that might be it
[11:50] <tsdgeos> wops
[11:50] <tsdgeos> the qsortmodelproxyfilter test is wrong :D
[11:51] <tsdgeos> http://paste.ubuntu.com/5712927/
[11:51] <tsdgeos> hard to see though
[11:52] <tsdgeos> the sad thing is that fixing it actually breaks one of the tests :S
[11:52] <Saviq> dandrader, why is that, btw? another thing - with your patch I can't actually dismiss the side stage
[11:53] <dandrader> Saviq, I don't know. I will leave that to another patch. It's not the purpose of this one to fix the side stage when running on the desktop
[11:53] <Saviq> dandrader, yeah that's fine, but the side stage integration is broken here
[11:53] <dandrader> Saviq, you can minimize it by dragging from the left edge
[11:53] <Saviq> dandrader, I actually can't
[11:53]  * dandrader checks again
[11:54] <Saviq> dandrader, my workflow: launch, maximize, log in, launch gallery -> side stage comes in
[11:54] <Saviq> which it should not
[11:55] <dandrader> Saviq, is it any different when you try it on trunk?
[11:55] <Saviq> dandrader, yes
[11:55] <tsdgeos> sil2100: the popups bug is fixed, yuhuuuuuuuu
[11:55] <Saviq> dandrader, when I try on trunk the main stage comes in
[11:57] <dandrader> Saviq, ah, ok. I see the difference now. but I still can minimize by dragging from the left edge both on trunk and with my patch
[11:58] <Saviq> Cimi, no, it's fine for now, just put a TODO/FIXME there
[11:58] <Cimi> ok
[11:59] <Saviq> tsdgeos, it removes from the beginning and not actually row + count-1?
[11:59] <Saviq> tsdgeos, ah no, it will remove row count number of times, so that looks right
[11:59] <Saviq> tsdgeos, what's wrong there?
[12:01] <Saviq> dandrader, so, I can drag the side stage away after an app (like phone) gets launched in the side stage
[12:02] <Saviq> dandrader, so there must be something out of sync (like the stack of apps in main / sidestage with the actual stage property on Application)
[12:04] <Saviq> Cimi, 865	+ lensView.lens.searchQuery = "test"
[12:04] <Saviq> 866	+ compare(lensView.lens.searchQuery, "test", "searchQuery not set as expected")
[12:04] <Saviq> Cimi, that's not really a test
[12:04] <Cimi> Saviq, indeed
[12:04] <Saviq> or at least not a test of something that we want to test
[12:04] <Cimi> Saviq, but I want to be sure that searchQuery gets set before proceeding
[12:05] <Saviq> Cimi, how can it not get set?
[12:05] <Cimi> Saviq, since it belongs to a fake local plugin...
[12:05] <Cimi> Saviq, bug in the local plugin
[12:05] <Saviq> Cimi, still, not the place to do that - the plugin should therefore have its own tests
[12:06] <Cimi> Saviq, ok
[12:09] <didrocks> fginther: hey, any idea why https://code.launchpad.net/~tiheum/unity/bfb_icon/+merge/159094 is not merging?
[12:20] <sil2100_> geh...
[12:21] <didrocks> sil2100_: any progress?
[12:22] <sil2100_> didrocks: almost, found the test that's causing the failure, but had some unity complications just now and was forced to reboot (a GPU hang)
[12:23] <sil2100> And also found the probable cause
[12:24] <seb128> sil2100, oh, what's the cause?
[12:50] <sil2100> seb128: ah, sorry, been playing on the guest session with AP
[12:52] <sil2100> seb128: so, heh, the open_new_application_window() method in test_panel is a bit broken when we don't have to 'maximize' or 'restore'
[12:54] <sil2100> seb128: in our case, somehow gedit gets remembered as maximized and starts off maximized, which sometimes causes a strange timing problem that in the end results in a funny thing: the application is being started (but still not visible), Alt is pressed (as we want to keep pressing it until the menu's appear on the panel), application then appears (and when an app appears, the menus appear instantly as well), the test thinks that the menu
[12:55] <sil2100> And HUD appears, even though we didn't ask it to
[12:55] <sil2100> Phew
[12:55] <sil2100> Experimenting with making it better
[12:56] <seb128> sil2100, cool, thanks for the details ;-) good luck improving it
[13:00] <tsdgeos> Saviq: uses endInsert instead endRemove
[13:01] <Saviq> tsdgeos, uh!
[13:01] <tsdgeos> eyah :D
[13:02] <Saviq> tsdgeos, btw, I'm going into a meeting now, seems your turn to be the minutes fairy on the standup if I won't make it back
[13:02] <tsdgeos> ok
[13:26] <paulliu> question: why tst_PeoplePreview is in qmluitests/Dash/ ? Why we don't put it in qmluitets/Dash/People ?
[13:28] <fginther> didrocks, bfb_icon is building now, nearly done
[13:28] <didrocks> fginther: what was the issue? huge backlog?
[13:28] <fginther> didrocks, yes, just a backlog today
[13:30] <didrocks> ok
[13:30] <tsdgeos> paulliu: yeah we could move it one more dir down
[13:31] <tsdgeos> Cimi: you coming?
[13:31] <sil2100> seb128, didrocks: https://code.launchpad.net/~sil2100/unity/autopilot_add_menu_settle_for_test/+merge/159156
[13:31] <tsdgeos> nic-doffay: you coming?
[13:31] <sil2100> This is actually the simplest and probably the most sane way of eliminating this problem
[13:31] <nic-doffay> tsdgeos, yep 1 sec
[13:33] <didrocks> sil2100: it makes sense to me, who should review that? (with your other autopilot branch?)
[13:33] <nic-doffay> tsdgeos, is anyone talking atm? Because I'm not hearing anyone.
[13:33] <nic-doffay> Mumble does this often.
[13:33] <tsdgeos> nic-doffay: we are talking
[13:42] <mzanetti> nic-doffay: qmlscene --desktop_file_hint=/path/to/some/file.desktop
[13:42] <mzanetti> nic-doffay: you can find .destop files in /usr/share/applications/
[13:43] <mzanetti> Saviq: ^
[13:43] <Saviq> mzanetti, nic-doffay, yup, that
[13:44] <sil2100> fginther: do you have a moment?
[13:44] <nic-doffay> Cheers Saviq !
[13:44] <fginther> sil2100, go ahead
[13:44] <mzanetti> you're welcome ;)
[13:44] <nic-doffay> And mzanetti
[13:44] <sil2100> fginther: https://code.launchpad.net/~sil2100/unity/autopilot_add_menu_settle_for_test/+merge/159156 <- hello! Can you make a quick review?
[13:44] <mzanetti> :P
[13:44] <nic-doffay> :P
[13:44] <sil2100> It's a big we encountered during daily builds
[13:45] <sil2100> fginther: there's also this... https://code.launchpad.net/~sil2100/unity/autopilot_disable_screen_lock <- but less urgent ;)
[13:47] <fginther> sil2100, reviewing the first one now
[13:47] <didrocks> fginther: the bfb icon failed :/
[13:47] <didrocks> fginther: for no reason
[13:47] <mzanetti> Saviq: speaking of which... can't we somehow get rid of that --desktop_file_hint? sucks big times imho
[13:47] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity/phablet.flatten-qmltests/+merge/159160
[13:47] <didrocks> https://code.launchpad.net/~tiheum/unity/bfb_icon/+merge/159094
[13:47] <mzanetti> Saviq: on it
[13:47] <didrocks> fginther: we really need this branch in before next daily ^
[13:47] <Saviq> mzanetti, the desktop file is the ID of the application
[13:48] <Saviq> mzanetti, we should later be able to expose that via a property on the surface, for example
[13:48] <mzanetti> Saviq: yeah... but all other DE's manage to do it without such a ugly parameter... we should be able to that too
[13:48] <kgunn> MacSlow: were you gonna rebase today ?
[13:48] <mzanetti> Saviq: exposing a property would only work for apps where we are upstream I guess?
[13:49] <fginther> didrocks, I'll get it in
[13:49] <didrocks> thanks fginther
[13:49] <fginther> sil2100, there will be a short delay on that review
[13:49] <Saviq> mzanetti, the question simply is - how do I match a surface to an application
[13:49] <MacSlow> kgunn, my notificationRenderer (on trunk) or my backend-frontend test-branch (on Jussi's backend-proto)?
[13:49] <Saviq> mzanetti, (see BAMF)
[13:50] <kgunn> MacSlow: renderer
[13:50] <Saviq> mzanetti, how do other DEs do that?
[13:50] <mzanetti> Saviq: yeah... but KWin doesn't use bamf and doesn't need a desktop_file_hint. I don't know how, but I know it must be possible somehow
[13:50] <MacSlow> kgunn, wasn't going to, but can do it now if you want to try it (tests) out
[13:50] <kgunn> MacSlow: i was just going to pull....but would wait if you said you were
[13:50] <MacSlow> kgunn, hold on...
[13:50] <kgunn> MacSlow: no worries....do what you think is first priority
[13:51] <nic-doffay> mzanetti, unable to find a .desktop file in that path.
[13:51] <Saviq> mzanetti, how does it then match windows to applications (does it actually care about applications, or, as it was usual, only about windows?)
[13:51] <mzanetti> Saviq: it does care about apps too
[13:51] <kgunn> MacSlow: do not let me wreck your train :)
[13:51] <mzanetti> Saviq: could be by some X11 thingie tho... as I said. I don't know implementation details
[13:51] <MacSlow> kgunn, there's not much left to wreck ;)
[13:52] <Saviq> mzanetti, if there was such a reliable X11 thingie, we wouldn't need BAMF ;)
[13:52] <mzanetti> nic-doffay: huh? no desktop files in /usr/share/applications/? I find that hard to believe
[13:52] <kgunn> MacSlow: hey...that's a nice thing to hear :)
[13:52] <Saviq> nic-doffay,  /usr/share/applications/qmlscene.desktop
[13:52] <mzanetti> Saviq: well... dunno... KDE can do it... thats all I know
[13:52] <MacSlow> kgunn, btw...seen that yet http://www.youtube.com/watch?v=7OH6T0ixhyA
[13:52] <larsu> Saviq, mzanetti: GtkApplication puts an x property on the window
[13:52] <mzanetti> Saviq: I can dig through the code on a lazy sunday afternoon
[13:53] <mzanetti> larsu: hmm... probably QApplication does so too
[13:53] <Saviq> larsu, mzanetti, yeah, that's what I thought - we will be able to do that via the toolkit
[13:53] <kgunn> MacSlow: quite nice
[13:54] <larsu> Saviq, mzanetti: we just agreed on the desktop summit to rename desktop files to include a full id (e.g. org.kde.konversation)
[13:54] <larsu> probably you want to do something similar :)
[13:54] <nic-doffay> Saviq, there's no qmlscene at that path.
[13:54] <Saviq> nic-doffay, on the device?
[13:55] <nic-doffay> Saviq, I wasn't looking on the device!
[13:55] <Saviq> nic-doffay, yeah, it's not there on your desktop - it's there on the device
[13:55] <Saviq> nic-doffay, you can `adb shell; ubuntu_chroot shell` into it
[13:55] <nic-doffay> Awesome thanks Saviq
[13:55] <Saviq> nic-doffay, or better yet `phablet-network-setup -i`
[13:55] <Saviq> nic-doffay, and ssh
[13:58] <MacSlow> Saviq, should test/qmltests/tst_NotificationRenderer.qml get its own subdirectory or rather be moved to Components?
[13:58] <Saviq> MacSlow, I already moved it into "interfaces" in my branch
[13:58] <MacSlow> Saviq, ah... ok
[13:59] <Saviq> dandrader, mzanetti, tsdgeos: "wrap to 90 columns" → fight!
[13:59] <mzanetti> haha
[13:59] <MacSlow> kgunn, I guess I'll don't re-base then and wait for Saviq's stuff to settle/land
[13:59] <kgunn> MacSlow: yep, no worries
[14:00] <Saviq> MacSlow, wtym? if you're using my branch, you've merged from it, no? so just merge again?
[14:00] <Saviq> mterry, we found out what was the autopilot problem
[14:00] <Saviq> mterry, look at ./run - we need to set LD_LIBRARY_PATH
[14:00] <Saviq> mterry, that's why the shell crashed and autopilot failed
[14:00] <mterry> Saviq, oh hmm
[14:01] <MacSlow> Saviq, I just used trunk... didn't know you about your branch
[14:01] <Saviq> mterry, obviously we need to fix the path
[14:01] <mterry> Saviq, is there a branch already?
[14:01] <Saviq> MacSlow, https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests/+merge/155914 you know about that
[14:01] <Saviq> mterry, no, not yet
[14:03] <Saviq> mzanetti, btw, can you please take care of fixing autopilot?
[14:03] <mzanetti> Saviq: yeah.. already contained in my last MP
[14:03] <Saviq> mzanetti, ah
[14:04] <Saviq> mterry, then there is a branch ^
[14:04] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-test-filtergrids/+merge/158941
[14:04] <mzanetti> Saviq: well... mterry's branch breaks something else
[14:04] <mzanetti> in a meeting now
[14:04] <Saviq> mzanetti, sure, but he wanted to test
[14:04] <dandrader> Saviq, on the device, what decides the actual size and position of an application window?
[14:04] <Saviq> mzanetti, k sorry
[14:04] <fginther> didrocks, bfb_icon is now merged
[14:04] <didrocks> thanks fginther :)
[14:05] <MacSlow> Saviq, sure
[14:05] <MacSlow> Saviq, just wanted to keep basing my branches on trunk as much as possible
[14:06] <Saviq> MacSlow, wait
[14:06] <Saviq> MacSlow, I think I misread
[14:06] <Saviq> MacSlow, yeah
[14:06] <Saviq> MacSlow, qmluitests/Notifications/
[14:06] <Saviq> MacSlow, sorry, you mentioned the interface tests before and I thought that's what you were talking about
[14:07] <Saviq> MacSlow, so yeah, under tests/ we're maintaining the same directory structure
[14:07] <Saviq> MacSlow, so tests/qmluitests/Notifications/
[14:07] <MacSlow> Saviq, ah ok
[14:08] <Saviq> dandrader, I'm not 100% sure, but I'd say they're fullscreen bar the panel height if not really fullscreen
[14:09] <dandrader> Saviq, on the tablet for instance. side-stage vs. main stage apps.
[14:09] <dandrader> Saviq, is their size hardcoded in the apps themselves
[14:09] <Saviq> dandrader, same, not in the apps
[14:10] <Saviq> dandrader, but in however we use SurfaceFlinger now
[14:11] <Saviq> dandrader, you got a conflict
[14:11] <dandrader> Saviq, already rebased
[14:11] <Saviq> dandrader, k
[14:21] <fginther> sil2100, approve
[14:21] <fginther> d
[14:22] <MacSlow> kgunn, re-based the renderer branch to trunk
[14:22] <sil2100> fginther: thank you!
[14:23] <kgunn> MacSlow: thanks dude!
[14:23] <sil2100> \o/
[14:27] <tsdgeos> lol
[14:27] <tsdgeos> m_list.insert(i+row, "test"+i);
[14:28] <tsdgeos> that +i is weird
[14:49] <Cimi> mzanetti, is the filter grid test enough for it?
[14:50] <Cimi> just one test on clicks?
[14:50] <Cimi> mzanetti, we're not even testing the APIs of filter grid
[14:52] <mzanetti> Cimi: there is tst_FilterGrid (without 's') that does the FilgerGrid API tests
[14:52] <mzanetti> Cimi: combining it with delegates and adding the clicked() signal is the only thing the *FilterGrids do
[14:53] <mzanetti> Cimi: that said. If you feel there is something missing, feel free to put a "Needs Fixing" there and I'll check it out
[14:53] <Cimi> ah ok
[14:53] <Cimi> sure
[14:58] <Saviq> mzanetti, tsdgeos, need opinion, /me wants to add a plugin with some utils for qml tests
[14:59] <tsdgeos> yes?
[14:59] <mzanetti> tests/plugins/
[14:59] <mzanetti> :P
[14:59] <Saviq> mzanetti, tsdgeos, those ended up in tests/plugins in my recent MP
[14:59] <mzanetti>  \o/
[14:59] <Saviq> mzanetti, tsdgeos, but then I want to add tests for that plugin ;)
[14:59] <tsdgeos> you want a test for the test?
[14:59] <mzanetti> tests for the mock plugin? sounds like a stack overflow to me
[14:59] <Saviq> mzanetti, not mock
[14:59] <Saviq> mzanetti, it's about the isInstanceOf()
[14:59] <Saviq> so some helpers
[15:00] <mzanetti> ah... then it might be in tests/utils/ imho
[15:00] <tsdgeos> Saviq: maybe even plugin/utils ?
[15:00] <Saviq> mzanetti, tsdgeos yeah, I thought about adding it ti /plugins/Utils
[15:00] <Saviq> and then the tests in /tests/plugins/Utils
[15:00] <mzanetti> I would split between utils we use for testing (e.g. UnityTestCase.qml) and mocks
[15:01] <Saviq> but then I don't want to put the test-useful-only things outside of /tests
[15:01] <mzanetti> yeah.. I for one would keep testing stuff in tests/
[15:02] <mzanetti> tests/mocks, tests/utils/
[15:02] <mzanetti> an in those we continue with imports/ and plugins/ in both
[15:02] <mzanetti> (no strong opinion on the naming - just about the directory structure)
[15:03] <tsdgeos> ok
[15:03] <tsdgeos> works for me
[15:03] <Saviq> mzanetti, so you'd put the mocks and utils outside of /tests/qmltests ?
[15:03] <mzanetti> Saviq: yeah... for example UnityTestCase is already used in unittests too
[15:04] <Saviq> mzanetti, and the tests for /tests/utils/ :D
[15:04] <Saviq> ?
[15:04] <Saviq> mzanetti, yeah, that's why I consolidated all qmltests together in that MP
[15:05] <Saviq> /we should put those test utils in the SDK and be done with it... ;P
[15:06] <mzanetti> Saviq: at the risk I'll loose my QE title now: if your testing-util would break, wouldn't we catch that by existing tests?
[15:06] <nic-doffay> Saviq, mzanetti I'm trying to copy files on the phone. What's the phablet password (when sudoing)
[15:06] <Saviq> nic-doffay, phablet
[15:07] <Saviq> mzanetti, to an extent, yes, but then I want TDD for it ;)
[15:08] <Saviq> mzanetti, and then if you don't have tests for the util, other tests fail but you'll have to hunt for the failure
[15:08] <Saviq> that otherwise could've been tested in a test of their own
[15:09] <mzanetti> Saviq: agree on that... however, it shouldn't be too hard to track the failure down to the util...
[15:09] <Saviq> mzanetti, too hard, but still harder
[15:09] <mzanetti> well. if you want to write tests for it, I'm not going to stop you
[15:09] <Saviq> +not
[15:09] <Saviq> lol
[15:09] <Saviq> yeah, just tell me where to put them, I'm recursing here!
[15:09] <mzanetti> put them either into tests/utils/tests or just tests/unittests/
[15:10] <Saviq> mzanetti, there is no tests/unittests anymore ;)
[15:10] <Saviq> but yeah
[15:15] <nic-doffay> mzanetti, what's the best method to edit the .desktop files from the shell?
[15:16] <Cimi> mzanetti, how do I see what's wrong here?
[15:16] <Cimi> mzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_LensView/+merge/159134/comments/349641
[15:16] <Cimi> where is s-jenkins now?
[15:16] <mzanetti> nic-doffay: by shell you mean qml-phone-shell or /bin/sh ?
[15:17] <mzanetti> nic-doffay: I guess the command line... pick your favourite editor... mine is "nano". others prefer vi or emacs
[15:17] <tsdgeos> mzanetti: do you want this one? https://code.launchpad.net/~aacid/unity/sortfilterproxymodelqml_split/+merge/159174
[15:17] <mzanetti> nic-doffay: nano doesn't work through adb shell... you need to use ssh for that
[15:18]  * mzanetti needs some sort of ticketing system
[15:18] <tsdgeos> mzanetti: i can find someone else :D
[15:19] <mzanetti> Cimi: unfortunately a bug in my jenkins setup somewhere (still)
[15:19] <mzanetti> Cimi: a rebuild should trigger
[15:19] <Cimi> ok
[15:19] <mzanetti> Cimi: a rebuild should fix
[15:19] <Cimi> mzanetti, but where is s-jenkins?
[15:19] <mzanetti> tsdgeos: I'll do
[15:24] <mzanetti> tsdgeos: can you elaborate on the reasoning?
[15:24]  * mzanetti has used QSortFilterProxyModels very often to sort AND filter in the past
[15:25] <tsdgeos> mzanetti: it's written in the commit log, it didn't work
[15:26] <mzanetti> tsdgeos: it says "...did collide a bit..."
[15:26] <tsdgeos> mzanetti: and then says "qFatal"
[15:26] <tsdgeos> :D
[15:26] <tsdgeos> mzanetti: you can also scroll up to this morning discussion with Saviq
[15:27] <tsdgeos> [11:07:09] downwards
[15:28] <mzanetti> I see... what is the difference between filtering and limiting?
[15:29]  * mzanetti reads docs...
[15:34] <tsdgeos> mzanetti: limit gives you a model with "x items"
[15:34] <mzanetti> tsdgeos: yeah... I fully understood it by now
[15:34] <mzanetti> thank
[15:34] <mzanetti> s
[15:35] <tsdgeos> mzanetti: btw i just pushed new stuff
[15:35] <tsdgeos> it contains the modeltest of Qt
[15:35] <tsdgeos> "should" be fine
[15:36] <tsdgeos> license wise i mean
[15:36] <nik90> does anyone know how to get the gio schema value of Unity indicator datetime from command line? I need to know if the system time format is 12 or 24 hour format.
[15:45] <mzanetti> tsdgeos: read-review done... a couple of t things to fix...
[15:46] <tsdgeos> mzanetti: can't assert otherwise the modeltest will assert :D
[15:47] <mzanetti> tsdgeos: ok... was just an idea... usually I don't like asserts, but this seemed like a legit place
[15:47] <tsdgeos> mzanetti: it's modeltest, it is that way
[15:47] <tsdgeos> that last one was a shitty sentence without the context in my head
[15:47] <tsdgeos> the "hi" qDebug
[15:47] <tsdgeos> it's in the "copied" code from modeltest
[15:47] <tsdgeos> qt5/qtbase/tests/auto/other/modeltest/modeltest.cpp
[15:48] <tsdgeos> i can filter it out if you want
[15:48] <mzanetti> tsdgeos: yeah.. fine with the test... but the emit in between the begin*Rows() and end*Rows() seems needs fixing to me
[15:48] <tsdgeos> sure can do
[15:48] <mzanetti> and the NOTIFY please too... the rest is subject to discussion
[15:48] <tsdgeos> your nitpick alert
[15:49] <tsdgeos> i'd copied from the other class
[15:49] <mzanetti> I think that's kaleo style, yeah
[15:49] <tsdgeos> i don't even like the function result being on one line all by itself
[15:49] <tsdgeos> but tried to "keep style in between brother classes"
[15:49] <mzanetti> yeah... hate it... but didn't want to nitpick too much
[15:49] <sil2100> didrocks: we'll be trying to get rid of the -ffmpeg dependency in mediaplayer-app, but renato say he would have to look into the available codecs
[15:50] <didrocks> sil2100: no workaround meanwhile? would be cool to have at least partial support for now
[15:51] <tsdgeos> mzanetti: about the Q_UNUSED vs comenteds params, i most of the times prefer commenting out because it has happened to me a lot that first i have a Q_UNUSED and then i use it but forgot to remove the Q_UNUSED
[15:51] <tsdgeos> and the code looks written by an idiot :D
[15:51] <mzanetti> tsdgeos: true...
[15:51] <sil2100> didrocks: they're using gstreamer to generate the thumbnails - so I guess we could somehow disable that for now
[15:52] <didrocks> sil2100: mind going on #ubuntu-touch?
[15:52] <sil2100> Or maybe enable it only when gstreamer is installed and add it as Suggests or something
[15:52] <sil2100> Ah
[15:55] <nic-doffay> mzanetti, what should the desktop file be changed to?
[15:55] <nic-doffay> The mandatory changes which will have to be made at least.
[15:56] <mzanetti> nic-doffay: dunno... why you want to change it?
[15:57] <mzanetti> nic-doffay: and which one? I don't know what exactly you want to do
[15:57] <mzanetti> nic-doffay: didn't you just want to launch qmlscene?
[15:58] <nic-doffay> mzanetti, basically I want to run my infographics.qml file on the phone.
[15:58] <nic-doffay> using qmlscene
[15:59] <mzanetti> nic-doffay: just run "qmlscene /usr/share/applications/qmlscene.desktop infographics.qml"
[15:59] <dandrader> Saviq, lp:~dandrader/unity/phablet_remove_fakes_from_qml is working fine on tablet mode now (side stage)
[15:59] <mzanetti> nic-doffay: err... "qmlscene --desktop_file_hint=/usr/share/applications/qmlscene.desktop infographics.qml"
[15:59] <tsdgeos> mzanetti: ok, comments addressed (i hope)
[16:00] <mzanetti> nic-doffay: doesn't matter which .desktop you choose. there just has to be passed one to make it appear in the running applications screen
[16:00] <nic-doffay> Ah I see
[16:00] <nic-doffay> thanks mzanetti
[16:03] <mzanetti> tsdgeos: I think you forgot one commit?
[16:03] <mzanetti> tsdgeos: the NOTIFY is not here yet
[16:06] <tsdgeos> maybe
[16:06] <tsdgeos> pushed
[16:07] <tsdgeos> EOD!
[16:08] <Cimi> dednick, I need to create a property in the plugin that is a model
[16:08] <Cimi> dednick, you know how to do that?
[16:09] <dednick> Cimi: what kind of model?
[16:09] <Cimi> dednick, it's the categories...
[16:09] <dednick> dont really understand. it should be the same as other objects
[16:09] <Cimi> dednick, they are using deelistmodel
[16:10] <Cimi> so I should use dee in the fake plugin too?
[16:10] <dednick> Cimi: you need to return results?
[16:10] <Cimi> I think so
[16:10]  * Cimi checks
[16:10] <dednick> Cimi: you can use dee. just need to create a local model.
[16:11] <dednick> let me find you an example
[16:12] <nic-doffay> mzanetti, this is what I'm attempting atm, nothing is coming up: qmlscene --desktop_file_hint=/usr/share/applications/weather-mockapp.desktop
[16:13] <mzanetti> nic-doffay: also pass a qml file
[16:13] <dednick> Cimi: unity_build/unity/tests/test_service_model.cpp
[16:13] <Cimi> ok
[16:13] <mzanetti> nic-doffay: and it won't pop up directly in fullscreen but minimized and you have to go to the apps lens and click on it in the running applications
[16:13] <dednick> Cimi: there's a category model in there
[16:13] <nic-doffay> mzanetti, any further instructions on how to achieve that?
[16:13] <mzanetti> Cimi:  I added a response to your comment https://code.launchpad.net/~mzanetti/unity/phablet-test-filtergrids/+merge/158941
[16:14] <mzanetti> nic-doffay: ?
[16:14] <mzanetti> you have your infographic.qml file copied to the device, don't you?
[16:15] <nic-doffay> Yeah shall I just run it from the root?
[16:16] <mzanetti> dandrader: re "Automatically wrapped lines are horrible to read." Manually wrapped lines too. especially if there would be enough space to not wrap it
[16:16] <nic-doffay> What's the best way to copy a file btw, just to make sure I've got the easiest method. mzanetti
[16:16] <dednick> Cimi: except create the DeeModel with dee_sequence_model_new instead of dee_shared_model_new
[16:16] <Cimi> dednick, ok
[16:16] <dednick> so it wont be exported on dbus
[16:17] <mzanetti> nic-doffay: I use scp. Its the easiest for me - might not be true for everyone...
[16:18] <dandrader> mzanetti, automatically wrapped lines break indentation. manually wrapped ones do not
[16:19] <nic-doffay> I'd like to give it a try mzanetti any pointers?
[16:19] <mzanetti> dandrader: still... You can't force everyone to use only one third of their screen just because you like to use very small windows ;)
[16:20] <mzanetti> nic-doffay: scp -h
[16:21] <mzanetti> nic-doffay: go with adb push if you haven't used scp before
[16:21] <dandrader> mzanetti, conversely, you can't force everyone to use only one code-window at a time just because you do ;)
[16:22] <mzanetti> dandrader: well... in that case I cope with automatically wrapped lines
[16:23] <mzanetti> dandrader: yeah... its a bit of a religious fight I guess... still it is possible to automatically wrap lines while its not possible to automatically unwrap them..
[16:23] <mzanetti> dandrader: what editor do you use btw?
[16:23] <dandrader> mzanetti, vim
[16:23] <fginther> jibel, ping?
[16:25] <jibel> fginther, pong
[16:25] <mzanetti> dandrader: that should offer a huge variety of auto-wrap plugins I guess. I'm sure there is one that wraps them in a way you like it :)
[16:25] <fginther> jibel, can you take a peek at https://jenkins.qa.ubuntu.com/job/cu2d-100scopes-experimental-2.2check/46/console please?
[16:25] <fginther> jibel, looks like the network failed during th etst
[16:25] <jibel> fginther, sounds bad, network failure ?
[16:26] <fginther> jibel, I mean the connection to launchpad
[16:26] <jibel> fginther, yes
[16:27] <fginther> jibel, thx
[16:27] <jibel> fginther, not much to do apart restarting the job
[16:27] <fginther> jibel, I'll try that, thanks
[16:28] <fginther> cyphermox, is it safe to restart a daily release job for 100scopes?
[16:28] <jibel> fginther, connection between magners and lp looks okay now
[16:29] <fginther> jibel, good
[16:29] <dandrader> mzanetti, I doubt it.
[16:57] <alecu> bregma: Hi, we are working on a unity branch for bug #1168674, and we are getting an error from jenkins under armhf: https://jenkins.qa.ubuntu.com/job/unity-ci/17/console
[16:57] <alecu> bregma: didrocks suggested we should contact somebody on your team. Is there a way to get more info from jenkins on the specific problem in the compilation?
[17:00] <bregma> fginther, can you answer the question from alecu on getting more detailed jenkins build logs ^^ ?
[17:00] <alecu> thanks!
[17:00] <bschaefer> alecu, heres some more info: https://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/17/console
[17:01] <bschaefer> https://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/17/
[17:01] <bschaefer> or the logs at lease...
[17:02] <bschaefer> err that was the SUCCESS one though...
[17:02] <alecu> https://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/17/console
[17:02] <bschaefer> alecu, IIRC, arm doesn't get build for CI
[17:03] <bschaefer> well looks like it is :)
[17:04] <bregma> lots of Failed to create file '/usr/share/glib-2.0/schemas/gschemas.compiled.487FVW': Permission denied type errors
[17:05] <bregma> bschaefer, I think they switched the armhf builds back on after aquiring some additional resources
[17:05] <bregma> given it's a key target architecture
[17:05] <bschaefer> o well thats nice, i remember them not have the resources before...itll be good to get arm under CI
[17:05] <bschaefer> bregma, it also looks like it hit a build timeout?
[17:05] <alecu> bregma: perhaps they also need to increase the timeouts on armhf, because the build seems to be killed: "Build timed out (after 120 minutes). Marking the build as failed."
[17:06] <bschaefer> Build timed out (after 120 minutes). Marking the build as failed.
[17:06] <alecu> bschaefer: ditto!
[17:06] <bschaefer> right
[17:06] <alecu> oh, 120 minutes, not seconds
[17:06] <alecu> 120 minutes seems like a reasonable timeout :P
[17:06] <bschaefer> that does...
[17:07]  * bschaefer wonders if it got stuck on that permission thing
[17:07] <bregma> 2 hours on pokey little memory-constrained armhf may not be completely reasonable
[17:08] <bschaefer> yay can't log into jenkins again ...
[17:09] <bregma> we'll leave resource configuration up to the good folks in QA who are responsible for that sort of thing
[17:09] <bschaefer> bregma, but it only got to 14%
[17:09] <bschaefer> yeaah, i figured if fginther wasn't around I could at lease restart it
[17:12] <alecu> bschaefer: it seems to have built unity to 100%, but the 14% is of a "make check-headless"
[17:12]  * bschaefer didn't view the full log
[17:13] <bschaefer> cool, well if thats the case then 120 min might be pushing it on arm
[17:14] <alecu> bschaefer: right. Old unity took ages to compile even on an i7 w/8 cores.
[17:14] <bschaefer> yeeah, its not to bad on i386 anymore, but last time i tried to compile unity on my nexus it took ~4 hours :)
[17:50] <fginther> alecu, jenkins is supposed to post the links to all of the buildlogs to the MP when it fails. I don't know why, but this was not included: https://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/17/console
[17:51] <fginther> alecu, but as you already found out, the build failed due to timeout.
[17:51] <fginther> alecu, the timeout was increased to 240 minutes starting with build 18. My apologies for not having restarted your job.
[17:52] <alecu> fginther: right, it posted the armhf log in the first comment of that MP, but not the second time: https://code.launchpad.net/~mandel/unity/plan-b/+merge/158383
[17:53] <alecu> oh, so it's really taking over two hours to build unity on armhf! poor cpus :-)
[17:54] <fginther> alecu, yes, it's a pain, although it was over 3 hours when we first started
[17:54] <alecu> fginther: so, you are able to restart it, right?
[17:55] <fginther> alecu, yes, and it's been queued
[17:55] <alecu> thanks!
[17:56] <fginther> alecu, No problem. My apologies for not noticing the timeout and restarting it when I increased the timeout
[17:57] <alecu> oh, nevermind...
[19:19] <kgunn> Saviq_: Saviq not which one you are :)
[19:20] <kgunn> Saviq: Saviq_  i just told dandrader he could look into the shell gesture handle/replay for app topic....
[19:43] <Saviq_> kgunn, yeah, I thought that would make sense