[02:02] <veebers> Saviq: Is the script runtests.sh in unity8 expected to work at this moment? Perhaps I'm not doing something right (and thus can update any docs)
[02:02] <Saviq> veebers, http://s-jenkins:8080/job/unity-phablet-qmluitests-trusty/ says it does...
[02:04] <veebers> ok thanks, I'll check that out
[02:06] <Saviq> veebers, just saw that mediumtests disable the edges demo - we should probably add that to the unity8 suite for test scripts to use
[02:07] <veebers> Saviq: ack, in the helpers section yeah?
[02:07] <Saviq> veebers, yeah
[02:07] <veebers> cool, can look into that
[03:08] <veebers> Saviq: are you still around?
[03:12] <sam113101> HELLO
[03:12] <sam113101> I'm having trubble with unity
[06:27] <Mirv> we'd now want ap1.4/xpathselect1.4 support back in, can someone check https://code.launchpad.net/~timo-jyrinki/unity/get_xpathselect_1.4_back/+merge/194069 ?
[08:05] <tsdgeos> oh lol
[08:05] <tsdgeos> the unity7 "panel" is crashing like crazy
[08:05] <tsdgeos> let me dist-upgrade again to see if it fixes itself
[08:08] <tsdgeos> looks like not
[08:11] <seb128> tsdgeos, can you get a bt?
[08:12] <tsdgeos> i should
[08:12] <tsdgeos> need to find out to which process to attach
[08:12] <tsdgeos> somehow it seems i disabled appport and don't know how to bring it back :D
[08:12] <seb128> tsdgeos, gdb -p $(pidof unity-panel-service)?
[08:12] <tsdgeos> sure, that should work :D
[08:13] <tsdgeos> seb128: http://paste.ubuntu.com/6369213/
[08:14] <tsdgeos> lol
[08:14] <tsdgeos> i have two network indicators too
[08:14] <seb128> tsdgeos, hum, ido, fun ... "dpkg -l - grep libido"?
[08:14] <tsdgeos> we're adopting the kde ideas? :D (KDE had the same problem with duplicated network stuff lately)
[08:14] <seb128> tsdgeos, that's normal if you installed e.g ubuntu-system-settings (that pulls in the new indicator, we still use nm-applet on the desktop)
[08:15] <tsdgeos> ii  libido3-0.1-0:amd64                                   13.10.0+14.04.20131105.1-0ubuntu1             amd64        Shared library providing extra gtk menu items for display in
[08:15] <seb128> tsdgeos, can you install libido3-0.1-0-dbgsym and get a new bt?
[08:15] <tsdgeos> sure
[08:16] <seb128> larsu, it seems like you have an invalid unref in your recent ido changes
[08:24] <tsdgeos> seb128: larsu: http://paste.ubuntu.com/6369241/
[08:24] <tsdgeos> i can valgrindize it if you guys want too
[08:29] <seb128> tsdgeos, I guess that would be useful, though it's likely due to http://bazaar.launchpad.net/~indicator-applet-developers/ido/trunk.14.04/revision/155
[08:32] <tsdgeos> seb128: do you remember the magic stuff i have to pass to valgrind when debugging glib programs so its useful?
[08:33] <seb128> tsdgeos, export G_SLICE=always-malloc G_DEBUG=gc-friendly
[08:35] <seb128> tsdgeos, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1248446 btw for tracking it
[08:38] <tsdgeos> seb128: hmmm, i'm having problems starting the panel-service under valgrind since killing it restarts it automatically and then the valgrind one says the bus is already taken, any clue how to make it not restart or to make the new one take over?
[08:39] <seb128> tsdgeos, stop unity-panel-service
[08:39] <seb128> "stop" as the upstart command
[08:39] <seb128> e.g type that
[08:39] <tsdgeos> that makes sense
[08:40] <tsdgeos> i'm not much into this upstart mindset :D
[08:40] <seb128> upstart job management is handy ;-)
[09:07] <tsdgeos> Saviq: look what i found yesterday http://picpaste.com/pics/IMG_00000616-b7AlTUm9.1383728804.jpg
[09:10] <Cimi> lol
[09:20] <larsu> seb128: oops. Already spotted it in that diff (g_file_icon_get_file() is transfer-none)
[09:20] <seb128> larsu, e.g g_object_unref (file); is wrong?
[09:20] <larsu> yes
[09:20] <larsu> I'll fix it right away
[09:26] <Saviq> tsdgeos, aaawww thank you :D
[09:26] <tsdgeos> wonder what was the guys idea to name it like that
[09:26] <tsdgeos> that or you have a second business here in barcelona and you never told us
[09:38] <nic-doffay> Saviq, I think this is ready when you have a moment: https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist
[09:38] <Saviq> nic-doffay, k
[09:43] <nic-doffay> Saviq, nm just saw your top comment.
[09:54] <nic-doffay> Saviq, where should I add this PageHeader test?
[09:54] <Saviq> nic-doffay, to the PageHeader tests
[09:54] <nic-doffay> Saviq, I meant searchHistory sorry.
[09:54] <Saviq> nic-doffay, ah no, DashContent or somewheer
[09:54] <Saviq> nic-doffay, you need to test that it's common between scopes
[09:54] <Saviq> nic-doffay, so you need one of the suites where there's multiple scopes
[09:54] <nic-doffay> Saviq, yeah.
[09:55] <nic-doffay> Saviq, taking a look at DashContent test now.
[09:56] <Cimi> can anyone tell me why system-settings-wizard does run but shows no window ? lp:~unity-team/ubuntu-system-settings/wizard-cmake
[10:06] <tsdgeos> Saviq: it's ok i keep triggering manual autolandings, right?
[10:06] <Saviq> tsdgeos, not now
[10:06] <tsdgeos> Saviq: wops
[10:06]  * tsdgeos hides
[10:06] <Cimi> hah
[10:07] <Saviq> tsdgeos, we're waiting for the autopilot 1.4 transition to settle
[10:07] <tsdgeos> ok
[10:07] <Saviq> tsdgeos, you're fine, just don't merge more
[10:08] <tsdgeos> sure
[10:11] <Cimi> if you are bored, I am stuccoed with lp:~unity-team/ubuntu-system-settings/wizard-cmake
[10:11]  * Cimi just saying
[10:18] <Mirv> Saviq: I was just about to say but I see you already spanked tsdgeos :)
[10:18] <Mirv> Saviq: I see three failing tests in unity8 with AP1.4
[10:18] <Saviq> Mirv, on mako?
[10:18] <tsdgeos> Cimi: what's the problem?
[10:18] <Mirv> Saviq: on mako, yes, http://pastebin.ubuntu.com/6369664/
[10:18] <Saviq> Mirv, I wasn't really paying attention, thought the ap guys will make sure they pass...
[10:19] <Mirv> Saviq: so did I. let me grab a log.
[10:19] <Cimi> tsdgeos, I run system-settings-wizard
[10:19] <Saviq> Mirv, oh well, they did pass http://10.97.0.26:8080/job/generic-mediumtests-trusty-touch/480/
[10:19] <Cimi> tsdgeos, the window does not appear
[10:21] <Saviq> Cimi, works fine here
[10:21] <Cimi> Saviq, wizard?
[10:21] <Saviq> ah wait, wizard
[10:21] <tsdgeos> Mirv: Saviq: then how did my thing get merged?
[10:21] <Saviq> Cimi, qrc:/qml/Pages/WelcomePage.qml:20 module "Ubuntu.SystemSettings.LanguagePlugin" is not installed ?
[10:21] <Saviq> tsdgeos, yeah, that as well
[10:21] <Cimi> Saviq, I did make install
[10:21] <Cimi> Saviq, then it finds the plugin
[10:22] <Cimi> Saviq, but still doesn't load the app
[10:22] <Saviq> Cimi, well, I won't...
[10:22] <Saviq> Cimi, view.show()
[10:22] <Saviq> Cimi, you never *show* the window, so it doesn't show
[10:23] <Cimi> I'm very embarassed
[10:23] <Cimi> I commented our viewFullscreen because doesn't work here
[10:23] <Mirv> Saviq: the attachment in bug #1248477
[10:23] <Cimi> but I did not replace it with show
[10:24] <Cimi> Saviq, sorry...
[10:24] <Cimi> spent so much time on the cmake without realising the issue was in the code :)
[10:26] <Saviq> Mirv, you got a .crash file?
[10:27]  * Saviq adds daily-build
[10:29] <Mirv> Saviq: no, the only crash I have is upstart-app-lauch
[10:29] <Saviq> Mirv, interesting...
[10:29] <Saviq> Mirv, how about ~/.cache/upstart/unity8.log ?
[10:31] <Saviq> Mirv, I'm running them locally now from daily-build, let's see what I get
[10:32] <Mirv> Saviq: http://people.canonical.com/~tjyrinki/u8/
[10:33] <Saviq> Mirv, to reduce tsdgeos's offence, he's merged a fix of one of the failing tests of unity8 on 5.2 ;)
[10:34] <Saviq> Mirv, ok, nothing obvious, testing locally - can you reliably fail those tests?
[10:36] <Mirv> Saviq: sure, that's great :) and yes those tests fail every time for me.
[10:36] <Saviq> Mirv, interesting
[10:41] <Saviq> Mirv, 22 tests OK here
[10:41] <Saviq> Mirv, I just installed unity8-autopilot from daily-build (and its dependencies)
[10:42] <Saviq> so it pulled in unity8 and friends, and libautopilot-qt 1.4
[10:42] <Mirv> Saviq: ok, weird. can you dpkg -l | grep autopilot to check also autopilot-touch is uptodate?
[10:52] <Saviq> Mirv, nope, it's not
[10:53]  * Saviq installs
[10:58] <Mirv> Saviq: ok I think it was again this /home/phablet/autopilot, or seems probable at least
[10:59] <Saviq> Mirv, right...
[11:04] <Saviq> Mirv, 22 OK with autopilot-touch, too
[11:05] <Saviq> false alarm, it seems
[11:05] <Mirv> Saviq: yep, mark the bug as invalid
[11:05] <Mirv> or I can
[11:05]  * Mirv did
[11:25] <dandrader> my "date & time" indicator disappeared (talking about ubuntu desktop trusty here). Has it happened for any of you guys? If so, is there an easy way to get it back?
[11:26] <seb128> dandrader, is indicator-datetime-service running?
[11:26] <tsdgeos> dandrader: run /usr/lib/x86_64-linux-gnu/indicator-datetime-service
[11:26] <tsdgeos> dandrader: happens randomly here
[11:26] <pabloff9> I'm also having this
[11:27] <seb128> tsdgeos, dandrader: does it happen at login? (that bug is supposed to have been fixed recently)
[11:27] <pabloff9> not on my PC now to test it, though
[11:27] <seb128> pabloff9, ^
[11:27] <tsdgeos> seb128: it happens randomly at login yes
[11:27] <tsdgeos> it may have been fixe
[11:27] <dandrader> seb128, no
[11:27] <seb128> tsdgeos, that was bug #1239710
[11:27] <dandrader> seb128, yes (for the second question)
[11:27] <seb128> tsdgeos, I didn't see the issue since I've the updates
[11:28] <tsdgeos> seb128: maybe, don't remember the last time it happened
[11:28] <dandrader> seb128, I just turned on my computer today and I noticed it was missing the date-time indicator
[11:28] <seb128> dandrader, dpkg -l | grep indicator-datetime
[11:29] <dandrader> seb128,  13.10.0+13.10.20131023.2-0ubuntu1
[11:29] <seb128> dandrader, did you just install upgrades?
[11:30] <dandrader> seb128, yes
[11:30] <dandrader> seb128, so rebooting will solve it then?
[11:30] <seb128> dandrader, ok, so maybe you just got that update
[11:30] <seb128> dandrader, well, restarting unity-panel-service should fix it
[11:30] <seb128> dandrader, e.g kill it or use "restart"
[11:30] <tsdgeos> Saviq: i honestly don't think i can fix the singleton issue myself in 5.2
[11:31] <dandrader> seb128, thanks. it did fix it! :D
[11:31] <Saviq> tsdgeos, meaning "our side"?
[11:31] <tsdgeos> unless i put hundred hours to understand the V4 code which I doubt we want to do
[11:31] <dandrader> seb128,  "restart unity-panel-service", I mean
[11:31] <tsdgeos> Saviq: well, it just broke, i can remove the test to fix it :D
[11:31] <seb128> yeah
[11:31] <Saviq> tsdgeos, we might need that temporarily
[11:32] <Saviq> tsdgeos, managed to talk to Qt guys about it?
[11:32] <tsdgeos> Saviq: i'll repport a new bug with regression in the topic
[11:32] <tsdgeos> nope
[11:32] <tsdgeos> they're all awol
[11:32] <Saviq> tsdgeos, slackers
[11:32]  * tsdgeos checks when DevDays SF happens
[11:32] <tsdgeos> today :D
[11:32] <Saviq> right, makes sense ;)
[11:32] <tsdgeos> so yeah
[11:33] <tsdgeos> i think they have a good excuse
[11:33] <Saviq> tsdgeos, so yeah, skip the failing test with a TODO and a QTBUG link
[11:33] <Saviq> tsdgeos, so as not to block the switch to 5.2 (assuming we'll actually work!?)
[11:33] <tsdgeos> Saviq: he he, well once it builds on the ppa we can test it easierly
[11:33] <Saviq> tsdgeos, indeed
[11:34] <dandrader> Saviq, https://code.launchpad.net/~dandrader/unity8/drag-crash-1228336/+merge/192183 is all green and happy. Can we have it in?
[11:34] <Saviq> dandrader, we're waiting for the autopilot 1.4 transition to conclude
[11:35] <dandrader> ah, ok
[11:35] <Saviq> dandrader, then we can merge again
[11:42] <Saviq> tsdgeos, do you know if QtC 3.0.0-beta is supposed to be buildable with 5.0?
[11:42] <Saviq> tsdgeos, README mentions that it requires 5.2 or 4.8 (with restrictions)... not sure it means that 5.0/5.1 should work with restrictions or not...
[11:42] <tsdgeos> not really uptodate with QtC but i remember reading something along the lines that would say "no"
[11:43] <Saviq> tsdgeos, 's what I thought
[11:45] <Saviq> Mirv, I've a branch that (almost - docs seem to be broken) builds QtCreator 3.0, want a look?
[11:45] <Saviq> Mirv, on that note, how do you do "syncing with upstream"? I usually just move the debian and .bzr folders over and commit the changes...
[11:46] <Saviq> but I'm sure there's a better, more established way...
[11:49] <Mirv> Saviq: ping bzoltan about that, please
[11:50] <Mirv> Saviq: I import the new upstream tarball with bzr import-upstream (I think, or was it merge-upstream..)
[11:50] <Mirv> Saviq: then commit that and make packaging changes as needed
[11:50] <nic-doffay> Saviq, unsure why this is failing now, I can't see anything in the logs. https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145
[11:50] <Saviq> Mirv, right, didn't know that :)
[11:50] <Mirv> Saviq: the Ubuntu plugin needs to be ported over to 3.0 before the QtC 3.0 itself can be considered. but push your branch somewhere anyhow.
[11:51] <Saviq> Mirv, yeah
[11:51] <Saviq> nic-doffay, that's temporary
[11:52] <Saviq> nic-doffay, autopilot 1.4 isn't yet published
[11:53] <Saviq> nic-doffay, restarted the job so that it picks up the daily-build ppa to get 1.4
[11:53] <nic-doffay> Saviq, cool.
[12:05] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/singleton_52/+merge/194123
[12:10] <Saviq> tsdgeos, thanks
[12:11] <dandrader> Saviq, do we still support SurfaceFlinger. It so, until when?
[12:11] <dandrader> s/It/If
[12:12] <Saviq> dandrader, "support" is an overstatement... but yeah, it's still there, hopefully not for long
[12:12] <Saviq> dandrader, i.e. if we regress on sf that's ~fine
[12:13] <dandrader> ok
[12:13] <Saviq> dandrader, once we get Mir on the Nexus10, I'll be pushing for dropping sf altogether
[12:16] <Saviq> dandrader, tsdgeos, fyi, once we get smoke results from the next image, and they're green for unity8, is when we can start merging again
[12:16] <tsdgeos> \o/
[12:16] <Saviq> tsdgeos, looking at https://code.launchpad.net/~aacid/unity8/singleton_52/+merge/194123... unity-notifications will fail as well, as they rely on it :/
[12:16]  * Saviq pushes unity-notifications to qt5-beta2
[12:16] <Saviq> Mirv, ok ↑?
[12:17] <tsdgeos> Saviq: do they
[12:17] <tsdgeos> that's bad
[12:17] <Saviq> tsdgeos, erm wait
[12:17] <Saviq> tsdgeos, I meant unity-api
[12:17] <Saviq> Mirv, ↑
[12:17] <Saviq> and the tests in there
[12:17] <Saviq> at least
[12:18] <Saviq> right, unity-api doesn't run the tests in autopkgtest... so they built just fine
[12:18] <tsdgeos> ok, i'll try to compile+test  unity-api againsst my 5.2
[12:18] <Saviq> tsdgeos, yes please, qml tests, that is
[12:23] <tsdgeos> Saviq: can you quick review this? i realized i had it in my qtubuntu from the roaming fixes i did on release day but was unpushed https://code.launchpad.net/~aacid/qtubuntu/const_ref/+merge/194126
[12:51] <Mirv> Saviq: ok, or do a recipe?
[12:52] <dandrader> ouch! I'm unable to build unity8 packages on the device: "c++: internal compiler error: Killed"
[12:55] <tsdgeos> lol
[12:55] <tsdgeos> dandrader: do you have enough disk space?
[12:58] <dandrader> tsdgeos, think so. "/dev/mmcblk0p12                15G  3.6G   11G  25% /home"
[12:58] <dandrader> standing for "Filesystem                    Size  Used Avail Use% Mounted on"
[13:07] <Saviq> dandrader, `powerd-cli active` as root
[13:07] <Saviq> dandrader, when it gets into low-powered mode, it will interrupt system calls under high load
[13:07] <dandrader> Saviq, ah, interesting.
[13:07] <Saviq> tsdgeos, "const QRectF & relativeGeometry" please fix spacing?
[13:08] <Saviq> dandrader, connecting to the PC (not charger) helps as well
[13:26] <mhr3> Saviq, so you were ok with the approach of taking unity and removing all the non scope bits to get the "scope test app"?
[13:27] <mhr3> one thing i kinda like about it is that we can keep merging things that get into unity
[13:27] <Saviq> mhr3, yeah, if you need to refactor some things to e.g. load Dash.qml directly, that might be a good solution as well
[13:27] <Saviq> mhr3, which would keep us even closer
[13:28] <mhr3> Saviq, meh, this works, although i do wonder what to do about tests
[13:28] <mhr3> i guess we don't really care about the ui tests and would be only interested in unit tests
[13:28] <mhr3> as in pure c++ unit tests
[13:29] <Saviq> mhr3, yeah, UI tests would happen on our side
[13:29] <mhr3> Saviq, but ultimately this setup isn't going to help much when merging back into unity, we'll loose all the history... problem?
[13:30] <Saviq> mhr3, or you could just work on lp:unity8 directly...
[13:30] <Saviq> mhr3, or... extract the Unity plugin first
[13:31] <Saviq> mhr3, and only work on lp:unity8 for the UI bits
[13:31] <Saviq> mhr3, and keep the unity plugin separate
[13:31] <mhr3> yes, lots of options, i'm not sure what the best
[13:32] <mhr3> anyway, pushed what i have to lp:~unity-team/unity8/unity-scopes-only
[13:33] <Saviq> mhr3, I'd like us to keep as close as possible, to not fork too much
[13:33] <Saviq> mhr3, so maybe indeed separating out the unity plugin would be good
[13:33] <Saviq> mhr3, you could fork that for the new scopes api
[13:33] <Saviq> mhr3, while we could keep all the UI changes in lp:unity8
[13:33] <mhr3> yea, it does sound sensible
[13:34] <mhr3> the question is whether there really won't be any qml-facing API changes
[13:34] <mhr3> if there are, things will get complicated
[13:36] <Saviq> mhr3, that's when we'll "fork" inside unity8
[13:36] <Saviq> mhr3, piece-by-piece
[13:36] <Saviq> mhr3, maybe we can even use Qt's versioning mechanism at that point
[13:37] <mhr3> qt has versioning? :)
[13:37] <Saviq> mhr3, yeah, you can tag members, for example, with revisions
[13:37] <Saviq> mhr3, and then, when you import a certain version, that one member will get imported or not
[13:37] <mhr3> how do you use it then in qml?
[13:37] <Saviq> mhr3, "import blah 1.1"
[13:38] <Saviq> mhr3, in qmldir you can specify which qml files correspond to which version of the import
[13:38] <mhr3> aaah
[13:38] <Saviq> mhr3, so a single plugin under Unity.1 can have different imports for Unity 1.0 and 1.1
[13:38] <mhr3> interesting
[13:39] <Saviq> would require some refactoring on unity8 side, but that's not necessarily bad anyway ;)
[13:39] <mhr3> heh
[13:39] <Saviq> Mirv, another question - is there a way to get the changed files into debian/changelog automagically?
[13:40] <mhr3> Saviq, so for the separated-out unity plugin, should i create a new lp project?
[13:40] <Saviq> mhr3, yeah, unity-scopes? ;)
[13:40] <Saviq> mhr3, unity-scopes-shell?
[13:40] <Saviq> mhr3, unity-qt?
[13:41] <mhr3> i like unity-scopes-shell
[13:41] <mhr3> since the other part is unity-scopes-api
[13:41] <Mirv> Saviq: maybe, but I don't know about such. I've used dch for changelog modifying otherwise.
[13:41] <sil2100> bregma: ping :)
[13:42] <bregma> sil2100, how may I help?
[13:42] <Saviq> mhr3, while you're at it, extracting abstract classes into lp:unity-api would be nice :)
[13:42] <mhr3> Saviq, that's the util lib, right?
[13:43] <mhr3> i know we're using it, but never actually looked at what's in there :)
[13:43] <sil2100> bregma: hello! Any progress in getting the fix for LP: #1247787 released?
[13:43] <sil2100> bregma: I think I saw didrocks mention something about the patch not being rebased on the latest ubuntu source?
[13:43] <Saviq> mhr3, not even util, just a place to keep API definitions (abstract base classes)
[13:43] <sil2100> didrocks: ^ can you comment?
[13:44] <Saviq> mhr3, and corresponding API tests that verify that an API is conformant with the requirement
[13:44] <mhr3> Saviq, hm, i guess it's time to look at it :)
[13:44] <Saviq> mhr3, it's not big :)
[13:44] <bregma> sil2100, the patch is the latest Ubuntu source with a patch cherry-picked from upstream, as the debdiff clearly shows
[13:44] <Saviq> mhr3, ah and yeah, there's utils from michi
[13:44] <Saviq> mhr3, not sure anything uses those, though
[13:44] <didrocks> sil2100: what should I comment? the branch is on 2.8.11.2-1ubuntu5 and we have 2.8.12-0ubuntu1 in trusty
[13:44] <mhr3> Saviq, i know the scopes-api is
[13:45] <didrocks> as well, I saw some inline diff, I would prefer a debdiff with only debian/patches/
[13:45] <sil2100> bregma: ^
[13:45] <Saviq> mhr3, okay, good, then
[13:45] <bregma> didrocks, the Ubuntu source keeps its patches applied -- not my pref, but I wasn;t going to break what's already there
[13:46] <bregma> the debdiff contains only the patch, the MP diff has the patch applied
[13:46] <didrocks> bregma: I saw one file applied (or maybe the diff was contracted)
[13:46] <didrocks> bregma: but is it on 2.8.12-0ubuntu1?
[13:46] <didrocks> I saw 2.8.11.2-1ubuntu5 in the branch
[13:47] <mhr3> Saviq, hm, there isn't really much besides the util classes, but from the dir layout it's very much an older copy of current scopes-api
[13:48] <nic-doffay> Saviq, there's one unrelated instability that jenkins has reported with the filters mp
[13:48] <Saviq> mhr3, there's more here http://bazaar.launchpad.net/~unity-team/unity-api/trunk/files/head:/include/unity/shell/
[13:48] <nic-doffay> https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145
[13:48] <Saviq> nic-doffay, yeah, saw that
[13:48] <bregma> didrocks, here's the debdiff attached to the bug: https://launchpadlibrarian.net/155893853/debdiff
[13:48] <Saviq> nic-doffay, that's just a flaky test
[13:48] <Saviq> mhr3, the shell APIs are not built into a lib even - they're just headers
[13:49] <mhr3> oh, didn't check the include dir :/
[13:49] <didrocks> bregma: ah nice, sponsoring that one then
[13:50] <Saviq> mhr3, the idea is that whoever wants to implement a shell-facing component
[13:50] <mhr3> Saviq, not exactly sure that's good... if we want to keep minimal changes, sure, otherwise it will be pita to maintain in there
[13:50]  * bregma thinks packaging branches should not be kept with patches applied in bzr
[13:51] <Saviq> mhr3, sure, we should only merge into lp:unity-api once we have a more-or-less stable API
[13:51] <nic-doffay> Saviq, I think this needs a rebuild too https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist/+merge/193935
[13:51] <Saviq> mhr3, not saying we should start with that
[13:51] <mhr3> Saviq, ok, then i'm fine with it
[13:52] <Saviq> mhr3, just extract the api in unity-scopes-shell into headers, and at some point we'll move them over to lp:unity-api
[13:52] <mhr3> yep, will do
[13:53] <Saviq> nic-doffay, the test checks for entries on the first scope twice, how does that check for persistence across scopes?
[13:53] <Saviq> nic-doffay, and it's doing that at too low a level
[13:53] <mhr3> but then this doesn't seem like a very good place for the util classes
[13:53] <Saviq> mhr3, lp:unity-api? might not be indeed
[13:54] <mhr3> seems kinda circular
[13:54] <Saviq> nic-doffay, it's just interrogating the same object, which is kind of useless
[13:54] <Saviq> nic-doffay, you should type into the search entry, switch scopes, focus the search entry and check that the history is correct
[13:54] <Saviq> nic-doffay, what you're testing there instead is whether the SearchHistoryModel works
[13:55] <Saviq> nic-doffay, which, granted, it might need (don't remember its coverage)
[13:55] <Saviq> nic-doffay, but still not a relevant test for that bug
[13:56] <nic-doffay> Saviq, all that would have to be done from the PageHeader.
[13:56] <Saviq> nic-doffay, why is that?
[13:56] <Saviq> nic-doffay, you just find a PageHeader child in the DashContent
[13:56] <Saviq> nic-doffay, based on its objectName
[13:57] <Saviq> nic-doffay, then find the text entry and type into it
[13:57] <nic-doffay> Saviq, I just presumed that those tests were best done from the PageHeader.
[13:57] <Saviq> nic-doffay, you can't do that there
[13:57] <Saviq> nic-doffay, as you don't have multiple scopes
[13:57] <Saviq> nic-doffay, just one PageHeader
[13:57] <nic-doffay> Saviq, right
[13:58] <Saviq> nic-doffay, or well, you could just create two PageHeaders
[13:58] <Saviq> nic-doffay, but that wouldn't test how it's really used
[13:58] <nic-doffay> Saviq, should I get rid of that other test that I wrote prior then?
[13:58] <Saviq> nic-doffay, what we need to make sure of there, is that the use case really works
[13:58] <Saviq> nic-doffay, the added test in that MP is not in the right place, at least
[13:59] <Saviq> nic-doffay, if you want to test that the SearchHistoryModel behaves as defined, that's a tst_SearchHistoryModel (if there isn't one)
[13:59] <Saviq> i.e. whether it adds / promotes entries as expected
[14:00] <Saviq> nic-doffay, what you need is basically a regression test for the bug
[14:00] <Saviq> nic-doffay, and do it on as low a level as possible, yes, but still such that it verifies that the user will see the same behavior
[14:01] <Saviq> otherwise you're testing the test setup itself / Qt / QML, which we don't want to do
[14:05] <sam113101> Saviq: help
[14:06] <Saviq> sam113101, please ask your question first
[14:07] <sam113101> Saviq: why do I get this?: http://imgur.com/a/vRRwR
[14:09] <Saviq> sam113101, no idea, I'm only working on unity8
[14:09] <Saviq> sam113101, is there a bug? if not - please file one
[14:10] <sam113101> Saviq: unity8 is the one that's not using compiz, right?
[14:10] <Saviq> sam113101, yes, the phone/tablet one currently
[14:10] <Saviq> sam113101, either way, it looks like a gtk theming issue
[14:10] <Saviq> sam113101, please file a bg
[14:10] <Saviq> bug
[14:11] <sam113101> under what "program", gtk? unity?
[14:11] <Saviq> sam113101, I can confirm it happens for me, too, under Radiance
[14:12] <sam113101> sweet, I thought it was only me
[14:12] <Saviq> sam113101, apport-bug light-themes
[14:12] <Saviq> that will send a launchpad bug to the light-themes project, which is where Radiance comes from
[14:12] <Saviq> and yikes my eyes hurt ;) it's so bright
[14:12] <seb128> Saviq, sam113101: "ubuntu-themes" is the correct project for that
[14:12] <seb128> we merged themes back in there some cycle ago
[14:13] <nic-doffay> Saviq, right. I have no idea how to access the PageHeader which lives in item which is the delegate of the loader on dashContentList using findChild.
[14:13] <Saviq> seb128, sure, apport-bug light-themes will file it there, no?
[14:13] <seb128> Saviq, oh, right, we still build that binary ... yes ;-)
[14:13] <Saviq> nic-doffay, just find the delegate based on its index (i.e. its objectName should be "scopeView" + index)
[14:14] <Saviq> nic-doffay, then you go var scopeView = findChild("scopeView0") or some such
[14:14] <Saviq> nic-doffay, and then scopeView.findChild("pageHeader") or similar
[14:14] <Saviq> nic-doffay, there's plenty of examples in the current tests
[14:24] <sam113101> https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1248558
[14:25] <sam113101> is unity8 only available on tablets and phones right now?
[14:34] <kgunn> dednick: mzanetti joining ?
[14:34] <Saviq> tsdgeos, http://pastebin.ubuntu.com/6370774/ that looks like broken docs in qtcreator
[14:34] <Saviq> does it not?
[14:34] <tsdgeos> Saviq: when does that happen? build stage?
[14:35] <Saviq> tsdgeos, yeah
[14:35] <tsdgeos> weird
[14:35] <tsdgeos> Cimi: ↑↑↑↑↑
[14:36] <sam113101> so, is unity8 available for desktops?
[14:37] <davmor2> sam113101: come back at 14.10 and unity8 should be available across the board
[14:38] <sam113101> that's a long time
[14:38] <sam113101> so unity will still be a compiz plugin on 14.04?
[14:38] <Daekdroom> sam113101, yeah, because Mir deployment was delayed.
[14:39] <sam113101> well, at least we'll have mir on 14.04, right?
[14:39] <Daekdroom> That's the plan, afaik.
[14:40] <sam113101> I'd like to work on mir and/or unity next, where should I start?
[15:08] <sam113101> seriously
[15:10] <tsdgeos> sam113101: there's a team meeting for unity8 happening, so people is not reading here, wait a 30 mins
[15:11] <tsdgeos> greyback: am i the only one that was kicked out of the hangout?
[15:11] <greyback> tsdgeos: yes
[15:17] <fginther> Saviq, ping
[15:18] <Saviq> fginther, otp
[15:18] <fginther> ack
[15:47] <sil2100> Trevinho: hi!
[15:47] <sil2100> Trevinho: can we get https://code.launchpad.net/~timo-jyrinki/unity/xpathselect-1.4/+merge/194077 approved and merged?
[15:47] <sil2100> Trevinho: is it ok?
[15:49] <sil2100> Trevinho: if yes, can you review and approve for merging?
[15:53] <dednick> Saviq: when you get a second, can you add the comment "will be used by unity8 and ubuntu-system-settings" to the ubuntu-settings-components landing request? I don't have write access.
[16:00] <Saviq> fginther, back
[16:02] <ChrisTownsend> sil2100: I'm reviewing that branch right now.
[16:03] <Saviq> sam113101, mir+unity8 is going to be an optional non-default session in 14.04
[16:03] <Saviq> sam113101, one that will provide mostly the tablet experience
[16:04] <Saviq> sam113101, if you want to help - code is in lp:unity8, here's some guidance on how to build it https://unity.ubuntu.com/getinvolved/development/unity8/
[16:04] <Saviq> sam113101, process is as usual - grab a bug you like, try and fix it and submit a merge proposal
[16:05] <sam113101> thanks
[16:09] <Saviq> dednick, done
[16:09] <dednick> Saviq: thanks
[16:09]  * Saviq recovers his throat
[16:14] <dednick> Saviq: /var/local/autopilot/setup.log:  unity8-autopilot : Depends: libautopilot-qt (>= 1.4) but 1.3+13.10.20130814-0ubuntu1 is to be installed
[16:14] <dednick> Saviq: known?
[16:15] <Saviq> dednick, yeah, we're transitioning from 1.3 to 1.4
[16:15] <dednick> Saviq: ok
[16:15] <Saviq> dednick, but it's not in the archive yet
[16:15] <Saviq> dednick, if you want you can add a hook to the job to add daily-build PPA with ap 1.4
[16:16] <fginther> Saviq, I noticed unity8 CI failures becuase of missing ap 1.4
[16:16] <fginther> ahh
[16:17] <Saviq> fginther, yeah, we don't have daily-build as default, was waiting for it to get into distro
[16:17] <fginther> Saviq, Ok, just checking. I won't touch anything
[16:19] <sil2100> ChrisTownsend: thanks!
[16:30] <sam113101> kind of weird, lol
[16:30] <sam113101> I don't really see myself using that on a desktop computer
[16:31] <sam113101> is there any working app?
[16:32] <ChrisTownsend> sil2100: I approved Timo's branch, and went ahead and globally approved.  I'm sure the merge will fail since we are still waiting on the cmake change, but I wanted to approve it for historical purposes:)
[16:33] <sil2100> ChrisTownsend: so the cmake change is still not there?
[16:33]  * sil2100 hoped it's released already
[16:33] <ChrisTownsend> Well, I think it's been sponsored, but I don't know the status of the upload and inclusion into the archive.  It may already be there for all I know.
[16:33] <sil2100> ChrisTownsend: thanks for approving anyway!
[16:34] <sil2100> Oh, ok, let me check that
[16:34] <nic-doffay> Saviq, the scopeView object doesn't contain a PageHeader in the test. It's FakeScopeView.
[16:35] <sil2100> ChrisTownsend: I see it's there, in -proposed, so depending if lp:unity is using -proposed or not for CI and merger, we might get it working
[16:36] <ChrisTownsend> sil2100: Ok, cool.  And I heard that Nux and Compiz are being removed temporarily from the daily-build PPA, right?
[16:37] <Saviq> nic-doffay, right...
[16:37] <Saviq> nic-doffay, ok, let's let it be - tsdgeos is doing things to the header anyway
[16:37] <Saviq> nic-doffay, we'll try and get the test in there
[16:37] <sil2100> ChrisTownsend: yes, we're holding of the transition for now, we need to finish 1.4 AP transition first
[16:38] <ChrisTownsend> sil2100: Ok, great!
[16:39] <nic-doffay> Saviq, can we land the branch without a test then?
[16:39] <Saviq> nic-doffay, yeah, not today though - still waiting for GO after the autopilot 1.4 transition
[16:39] <nic-doffay> Saviq, cool.
[16:39] <sam113101> "qml phone shell", is it what it's going to be like on the desktop, too?
[16:41] <Cimi> tsdgeos, weird, I subscribed myself
[16:42] <Saviq> sam113101, that's an old name, where did you find it?
[16:42] <sam113101> Saviq: that's the title of the app I've just run
[16:42] <ChrisTownsend> sil2100: Autolanding failed with the cmake error, so I guess it doesn't pull from -proposed.
[16:42] <Saviq> sam113101, right ;)
[16:42] <Saviq> sam113101, that can be your first contribution :)
[16:42] <Saviq> sam113101, it's the window title in main.cpp
[16:44] <ChrisTownsend> sil2100: How wonder how long cmake will be in -proposed...
[16:44] <sam113101> https://unity.ubuntu.com/getinvolved/development/unity8/
[16:44] <sam113101> what's the name supposed to be?
[16:52] <sil2100> ChrisTownsend: tahdah! It's in release already, re-approving the branch ;)
[16:52] <ChrisTownsend> sil2100: Alright!
[17:36] <sam113101> seriously though, the thing I'm using right now will be used on the desktop too?
[17:36] <sam113101> serious question
[18:27] <cwayne> sam113101: eventually.  as i understand it though, it won't look like that
[18:28] <cwayne> it will look like unity7, but be the same codebase as unity8
[19:16] <fginther> Saviq, can you assign https://blueprints.launchpad.net/ubuntu/+spec/core-1311-upstream-merger-20 to ~canonical-ci-engineering? or do you want to own this BP :-)
[19:32] <Saviq> fginther, doing :)
[19:33] <fginther> Saviq, thanks
[19:34] <fginther> Saviq, by the way, now that we have https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ci-airline, I'd like to retool core-1311-upstream-merger-20 some to not overlap as much
[19:34] <Saviq> fginther, feel free
[19:35] <Saviq> fginther, it does cover a lot of the same ground
[20:09] <sam113101> cwayne: good thing, unity7 is kind of buggy
[21:58] <veebers> Saviq: are you still around perchance?
[22:07] <Saviq> veebers, here
[22:07] <veebers> Saviq: hey, I'm experiencing issues with unity when I stop/start maliit-server. Is this a known/expected thing?
[22:08] <veebers> Saviq: specifically, this is with the autopilot tests that starts the maliit-server with testability. I can run a single test fine one, if I try run that single test again it will fail
[22:08] <veebers> either the tap won't register on the test app (nor can I tap it myself) or there is some sort of crash
[22:09] <Saviq> veebers, not sure, what exactly are you testing?
[22:09] <veebers> Saviq: this is the ubuntu-keyboard test
[22:09] <veebers> s
[22:10] <Saviq> veebers, the only thing I can think of
[22:10] <Saviq> veebers, is the OSKController from unity-mir
[22:10] <Saviq> veebers, it might not have connected to the keyboard yet
[22:10] <Saviq> veebers, you should see some messages about KeyboardInfo in unity8's log when you restart maliit
[22:10] <Saviq> that it disconnected from the socket
[22:11] <Saviq> veebers, that's because OSK needs to communicate its geometry to the shell, so that it sets everything up for it
[22:11] <veebers> Saviq: I see something like: UbuntuKeyboardInfo - socket error: "QLocalSocket: Remote closed"
[22:11] <veebers> I also had this once, repeated heaps:
[22:12] <veebers> __pthread_gettid -2
[22:12] <veebers> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[22:12] <veebers>   what():  display factory cannot create fb display
[22:12] <Saviq> veebers, that means something's hogging the display and unity8 can't start
[22:12] <Saviq> veebers, like an app (or maliit itself, for that matter)
[22:13] <Saviq> veebers, here's the keyboard info receiver http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/modules/Unity/Application/ubuntukeyboardinfo.h
[22:13] <Saviq> veebers, it's just a socket in XDG_RUNTIME_DIR
[22:13] <Saviq> veebers, over which ubuntu-keyboard sends some info about itself
[22:14] <Saviq> it's not ideal, but it does the job while we can't come up with a better solution
[22:15] <Saviq> veebers, it might be that you need to instrument it and wait for it to reconnect after restarting maliit
[22:17] <veebers> Saviq: when you say 'instrument it' you're referring to the better solution?
[22:17] <Saviq> veebers, no, the current one
[22:18] <Saviq> veebers, I don't think it exposes a property you could listen on
[22:19] <Saviq> OSKController.qml has an "enabled" property though
[22:19] <veebers> Saviq: right, and the ubuntu-keyboard side would also know when it's connected right? I could also do it on that side?
[22:19] <Saviq> veebers, yeah,
[22:20] <Saviq> veebers, m_clientConnection
[22:20] <Saviq> veebers, in http://bazaar.launchpad.net/~phablet-team/ubuntu-keyboard/trunk/view/head:/src/plugin/ubuntuapplicationapiwrapper.cpp
[22:22] <veebers> Saviq: ok understood. I need to wait until the keyboard/shell are connected. I'll see what I come up with
[22:38] <veebers> Saviq: hey, if you have a couple more minutes. I might be being dense, but what exactly is unity-mir. It's not a process that's running is it, I'm wondering how (if at all) i might be able to introspect it
[23:20] <Saviq> veebers, it's a plugin loaded into unity8
[23:21] <Saviq> veebers, i.e. import Unity.Application 0.1
[23:21] <Saviq> veebers, from which OSKController is instantiated in Shell.qml:739
[23:22] <Saviq> veebers, and that you can introspect talking to unity8
[23:22] <veebers> Saviq: ah right, thanks :-)