[09:16] <tsdgeos> Mirv: any chance you can add https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1253120 to the Qt 5.2 beta2/RC packages so we get egl again on the desktop?
[09:24] <Mirv> tsdgeos: right, I tried and it didn't apply for some reason, I mean the configure sections looked different. I was thinking to wait RC, but then it looks the RC isn't similar to what you submitted either.
[09:24] <tsdgeos> hmmm ?¿
[09:25] <tsdgeos> that's for the stable branch
[09:25] <tsdgeos> how can it have diverged that much
[09:25] <Mirv> tsdgeos: yeah, I know. it's not much but the if logic is different so I was a bit cautious.
[09:26] <Mirv> tsdgeos: http://pastebin.ubuntu.com/6488707/ - there's that top if [ "$CFG_OPENGL" != "es2" ]; then
[09:27] <Mirv> but I guess it would be maybe removing similarly the "$CFG_OPENGL" = "no" and elif
[09:28] <Mirv> by the way, still no real RC http://download.qt-project.org/development_releases/qt/5.2/
[09:29] <tsdgeos> yeah...
[09:31] <tsdgeos> Mirv: yeah same thing applies
[09:35] <Saviq> tsdgeos, that doesn't seem to have worked completely https://jenkins.qa.ubuntu.com/job/ubuntu-ui-toolkit-trusty-amd64-ci/295/console
[09:35] <tsdgeos> Saviq: yeah
[09:36] <tsdgeos> Saviq: didn't realize i was just running the test manually
[09:36] <tsdgeos> not thorugh the make check thing
[09:36] <tsdgeos> that passes -minimal
[09:36] <Saviq> tsdgeos, yeah, looks like you need to swallow the -platform arg
[09:36] <tsdgeos> or make it not be passed by the make
[09:36] <Saviq> tsdgeos, or well, QT_QPA_PLATFORM=minimal instead would work, too
[09:36] <tsdgeos> yeah
[09:37] <tsdgeos> or swallow it :D
[09:38] <Saviq> tsdgeos, yeah, it's probably a common set of args?
[09:39] <tsdgeos> all the other ones work fine
[09:39] <tsdgeos> i.e. -maxwarnings 10 -o ../../test_tst_arguments.xml,xunitxml -o -,txt
[09:39] <Saviq> yup
[10:26] <tsdgeos> mhr3: there?
[10:26] <mhr3> tsdgeos, yep
[10:26] <tsdgeos> mhr3: i don't understand how https://code.launchpad.net/~mhr3/unity8/ensure-currentitem-non-null/+merge/196948 makes set_current_index not get lost
[10:27] <mhr3> tsdgeos, cause it doesn't use setCurrentScopeAtIndex
[10:27] <mhr3> that is what invalidates it
[10:28] <mhr3> or well... resets it
[10:29] <tsdgeos> mhr3: but why do you need to set it at all?
[10:30] <tsdgeos> when it gets loaded it'll be set to the correct value anyway
[10:30] <tsdgeos> or
[10:30] <tsdgeos> in case we don't have one
[10:30] <tsdgeos> right
[10:30] <mhr3> and you answered yourself :)
[10:31] <tsdgeos> mhr3: i think the code would be a little easier to read if you had an outer if (count > 0)
[10:31] <tsdgeos> but that may as well just be my brain
[10:32] <tsdgeos> so this may actually be the proper fix to the dash content test unstability we have
[10:32] <tsdgeos> and not cimi's 5 to 10 seconds
[10:32] <mhr3> i was thinking about it
[10:32] <mhr3> but meh, it's 4 loc :P
[10:33] <tsdgeos> mhr3: what i'm not so sure is about how you
[10:33] <tsdgeos> dashContentList.currentIndex = -1; in the test
[10:33] <tsdgeos> should this be a verify and have that code in the onCountChanged?
[10:33] <mhr3> tsdgeos, not visible in the diff, what the -1 is in cleanup()
[10:33] <mhr3> s/what/that/
[10:34] <tsdgeos> sure
[10:34] <tsdgeos> i knew it was there
[10:34] <tsdgeos> still
[10:34] <tsdgeos> it means that dashContentList it's not cleaning up itself much
[10:34] <tsdgeos> so will the code you added in DashContent.qml work in real life
[10:34] <tsdgeos> without the extra cleaning you're doing in there?
[10:34] <mhr3> tsdgeos, listview itself is very odd how it behaves there
[10:35] <tsdgeos>  listview itself is very odd
[10:35] <tsdgeos> yep :D
[10:35] <mhr3> tsdgeos, basically i added it so the test_current_index would actually pass
[10:35] <mhr3> cause if it wasn't run as the first thing it'd fail on the currentIndex == -1
[10:36] <mhr3> yet if it was run as the first test it passed
[10:36] <tsdgeos> right
[10:36] <tsdgeos> and that's why i am saying that it makes sense to have
[10:36] <tsdgeos> dashContentList.currentIndex = -1;
[10:36] <tsdgeos> as else
[10:36] <tsdgeos> in that count > 0 of your countChanged
[10:37] <mhr3> i'm not sure, what if you want to reset the model?
[10:37] <mhr3> ie you'll see count 7 -> 0 -> 7
[10:37] <mhr3> if you don't force currentIndex to -1 you'll actually keep the same active page open
[10:39] <tsdgeos> if you to 7 -> 0 -> 6 -> 7
[10:39] <tsdgeos> you won't
[10:39] <mhr3> right, but at least it'll be approximately there :)
[10:40] <tsdgeos> and that's probably what will happen anyway 7 -> 0 -> 1 -> 2 -> 3 ...
[10:40] <mhr3> well if we don't forcefully set it to -1 we have the option of keeping the same page active
[10:40] <mhr3> if we do, we loose it
[10:40] <mhr3> end of story :)
[10:41] <Cimi> who has bugs for me?
[10:41] <tsdgeos> sure
[10:41] <tsdgeos> mhr3: i don't see how that counters the fact that you had to add extra code in cleanup to make your test work
[10:43] <mhr3> tsdgeos, tests should start in the same base environment, the component itself can remember state if it chooses to
[10:43] <mhr3> putting the reset in the component seems wrong
[10:44] <tsdgeos> well you're testing it
[10:44] <mhr3> cause you're closing the doors on keeping the state
[10:44] <tsdgeos> you test says
[10:44] <tsdgeos> compare(dashContentList.count, 0, "DashContent should have 0 items when it starts");
[10:44] <tsdgeos> compare(dashContentList.currentIndex, -1, "DashContent's currentIndex should be -1 while there are no items in the model");
[10:44] <tsdgeos> but that is simply not true
[10:44] <tsdgeos> you're totally arguing that the component is allowed to have dashContentList.currentIndex as not -1 even if there are no items in the model
[10:45] <mhr3> it is if all the tests were isolated
[10:45] <tsdgeos> so either your test is wrong
[10:45] <tsdgeos> or your component is wrong
[10:45] <tsdgeos> no
[10:45] <tsdgeos> you specifically wrote
[10:45] <tsdgeos> "DashContent's currentIndex should be -1 while there are no items in the model"
[10:45] <tsdgeos> no
[10:45] <tsdgeos> "DashContent's currentIndex should be -1 while there are no items in the model at the beggining of the program but not after because i think it makes sense to keep it"
[10:45] <tsdgeos> right?
[10:45] <mhr3> then i'll change it to "while there have been no items..." ;)
[10:46] <tsdgeos> mhr3: well, do it
[10:46] <tsdgeos> at least it won't be lying
[10:47] <mhr3> tsdgeos, fine with me, do you want the count if split too?
[10:47] <tsdgeos> mhr3: i'll leave it to you
[10:53] <mhr3> pushed
[10:54] <tsdgeos> tx ;.)
[10:56] <mhr3> btw tryCompare() really silly name
[10:57] <mhr3> when it's actually waitUntil()
[10:57] <dandrader> waitUntil with a timeout
[10:58] <mhr3> waitUntilWithTimeout() would be silly too :)
[10:59] <tsdgeos> mhr3: actually...
[11:00] <tsdgeos> mhr3: maybe we can have two tests?
[11:00] <tsdgeos> have one do dashContentList.currentIndex = -1; at the beginning (as if coming from a clean startup)
[11:00] <tsdgeos> and the other do dashContentList.currentIndex = 900; at the beginning (as if coming from a weird model)
[11:00] <tsdgeos> and then on both you test that at the end dashContentList.currentIndex == 0 or something?
[11:02] <tsdgeos> whatcha think?
[11:04] <mhr3> tsdgeos, well, that's kindof already tested in the set_current_scope_index_async
[11:04] <mhr3> but not directly, so ok...
[11:07] <tsdgeos> tx!
[11:42] <tsdgeos> Saviq: ci still borked, right?
[11:44] <mzanetti> Saviq: can you tell me what to do in order to run the real application manager instead of the mock with run_on_device? I just can't seem to find the right place
[11:50] <nic-doffay> tsdgeos, Q_SCRIPTABLE? Can't seem to find any info on it. (In dbusscreen.h)
[11:50] <tsdgeos> makes it dbus friendly amonsgt other things
[11:51] <tsdgeos> like making it also a Q_INVOKABLE
[11:58] <Saviq> tsdgeos, yeah, we're fighting, should be good soon
[11:58] <Saviq> mzanetti, right! that's actually a bug
[11:59] <Saviq> mzanetti, it was working before
[11:59] <Saviq> mzanetti, somehow QML2_IMPORT_PATH is borked
[11:59] <Saviq> mzanetti, unity-mir installs it in /usr/lib/arm-linux-gnueabihf/qt5/imports/Unity-Mir/
[11:59] <Saviq> mzanetti, and main() adds it
[12:00] <Saviq> mzanetti, main.cpp:155
[12:00]  * Cimi flashing nexus 10
[12:00] <Saviq> mzanetti, and somehow that started to fail
[12:04] <Saviq> mzanetti, most likely the set of import paths is constructed in the wrong order
[12:04] <mzanetti> mhm... I was playing around with that. but it always fails to find it
[12:07] <greyback> tsdgeos: Q_SCRIPTABLE doesnt seem to mean anything. src/corelib/kernel/qobjectdefs.h defines it as just "#define Q_SCRIPTABLE"
[12:08] <tsdgeos> sure
[12:08] <tsdgeos> it's just moc and others that make magic happen
[12:08] <greyback> ah
[12:08] <tsdgeos> it's like emit
[12:08] <tsdgeos> well not really
[12:08] <greyback> yep
[12:08] <tsdgeos> emit is really nothing
[12:08] <tsdgeos> noone cares
[12:17] <tsdgeos> btw i lost the user indicator and the volume indicator in unity7
[12:18] <tsdgeos> oh
[12:18] <tsdgeos> it's unity8 playing up with them
[12:18] <tsdgeos> damnit
[12:18] <tsdgeos> run unity8
[12:18] <tsdgeos> have sound and wifi indicators
[12:18] <tsdgeos> kill it
[12:18] <tsdgeos> indicators gone
[12:18] <tsdgeos> :D
[12:38] <Saviq> greyback, landings are b0rked until mir gets published, so no point in top-approving unless you kick generic-land by hand
[12:38] <Saviq> greyback, which I'll do in a minute
[12:39] <greyback> Saviq: ah really, wasn't aware of that
[12:39] <Saviq> greyback, bug #1255578
[12:40] <Saviq> greyback, it got fixed long-term by removing daily-build from the jobs
[12:40] <Saviq> but we're still deadlocked until Mir's published
[12:40] <Saviq> and then there's bug #1255948 which means we can't even use daily-build for a one-off job ;?
[12:40] <Saviq> so will push manually
[12:41] <greyback> Saviq: I am as confused as you though. How did it happen?
[12:41] <Saviq> greyback, daily-build was enabled by default for unity-mir -ci and -autolanding
[12:42] <Saviq> greyback, so it built, got put into the local per-stack repository for unity8 stack
[12:42] <Saviq> greyback, but unity8 isn't using daily-build (and shouldn't)
[12:42] <Saviq> nothing should
[12:42] <Saviq> so then you couldn't install libunity-mir1 from the mbs repo
[12:42] <mzanetti> Saviq: finally :) https://code.launchpad.net/~mzanetti/unity8/fix-appmanager-on-device/+merge/197053
[12:42] <Saviq> 'cause it wanted new mir
[12:43] <Saviq> mzanetti, that should be there from /etc/environment
[12:43] <Saviq> mzanetti, I mean imports
[12:43] <mzanetti> Saviq: yeah... it is when I query it in the shell. somehow exec_with_ssh doesn't pick that stuff up
[12:43] <greyback> Saviq: what's wrong with daily-build?
[12:43] <Saviq> mzanetti, also, will conflict https://code.launchpad.net/~saviq/unity8/tweak-run-scripts/+merge/196871
[12:44] <Saviq> greyback, it's unsafe - stuff in there might never end up in distro
[12:44] <mzanetti> Saviq: ah ok, perfect. I'll drop the conflicting change
[12:44] <Saviq> mzanetti, there's also a possible fix to do in exec_with_ssh then
[12:44] <Saviq> mzanetti, instead of what you did
[12:45] <Saviq> mzanetti, does exec_with_ssh use sudo -u phablet -i?
[12:45] <Saviq> mzanetti, that's the way to pick up the correct environment
[12:45] <Saviq> mzanetti, let's fix it at its root
[12:45] <mzanetti> Saviq: but when I just ssh into the phone it's there too
[12:45] <Saviq> mzanetti, yeah, that's because it's interactive
[12:45] <greyback> Saviq: understood. Pity though
[12:45] <Saviq> mzanetti, i.e. bash
[12:46] <Saviq> greyback, why?
[12:46] <greyback> Saviq: handy if you wanted to live on cutting edge :)
[12:46] <Saviq> greyback, you can still use it
[12:46] <Saviq> greyback, but -ci nor -autolanding should live on cutting edge, should they?
[12:47]  * Saviq always gets confused with the rules around neither / nor / or / not
[12:47] <Saviq> was that sentence syntactically correct ↑↑?
[12:48] <greyback> Saviq: neither/nor usually
[12:48] <Saviq> greyback, yeah, but if there's "not" somewhere already, neither/nor is wrong to use, right?
[12:48] <Saviq> greyback, i.e. something should not do foo, neither should bar
[12:49] <greyback> Saviq: right, then you'd use "nor"
[12:49] <Saviq> yeah, that's why I said I'm confused ;)
[12:49] <greyback> it all makes perfect sense :P
[12:53] <mhr3> i think english should have xor as well then
[12:53] <mhr3> example "you either agree or not" -> "you agree xor not"
[12:53] <mzanetti> Saviq: this does look correct to me: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -t phablet@localhost -p 2222 sudo -u phablet -i bash -ic \"echo $QML2_IMPORT_PATH\"
[12:53] <tsdgeos> guys, a little more killing https://code.launchpad.net/~aacid/unity8/remove_unused_applications_folder/+merge/197058
[12:54] <tsdgeos> and that said
[12:54] <tsdgeos> lunch!
[12:55] <Saviq> mzanetti, yeah, does this work with exec_with_ssh?
[12:56] <Saviq> mzanetti, if not - we should find out why - as we're bound to actually lose more env then just import path
[12:56] <mzanetti> Saviq: yeah... it doesn't work
[12:56] <mzanetti> strangely
[13:02] <Saviq> mzanetti, exec_with_ssh 'echo ${QML2_IMPORT_PATH}'
[13:02] <Saviq> mzanetti, that drops /usr/lib/arm-linux-gnueabihf/qt5/imports for me
[13:03] <mzanetti> not here
[13:03] <Saviq> mzanetti, TBH I think my branch should fix the issue
[13:03] <Saviq> mzanetti, the pkg-config was the cause
[13:03] <Saviq> mzanetti, as it was overwriting the path
[13:04]  * Saviq tries
[13:09] <mzanetti> Saviq: nope... tried with your branch... not in there
[13:11] <Saviq> mzanetti, yeah, I mean I'm trying run_on_device for real with my branch
[13:11] <Saviq> mzanetti, AFAICT it should come up with real apps plugin
[13:11] <mzanetti> no. it doesnt
[13:11] <Saviq> 200MB deps...
[13:11] <mzanetti> that's what I just did
[13:11] <Saviq> mzanetti, ok, but yours does not echo the import path to start with ;)
[13:12] <Saviq> mzanetti, just let me try
[13:13] <mzanetti> ok. grabbing something to eat
[13:14] <Saviq> mzanetti, ok, not working indeed
[13:14]  * Saviq prints the import path
[13:14] <Saviq> s
[13:31] <mzanetti> Saviq: what's the verdict?
[13:31] <Saviq> mzanetti, something's stupid
[13:31] <mzanetti> told ya :D
[13:32] <mzanetti> no clue why it doesn't pick up the env
[13:32] <mzanetti> probably some very restrictive check in some of the env scripts
[13:32] <Saviq> mzanetti, but really, exec_with_ssh "\${QML2_IMPORT_PATH}" doesn't work?
[13:32] <Saviq> mzanetti, it's completely stupid
[13:32] <Saviq> mzanetti, in:
[13:32]  * mzanetti tries again
[13:32] <Saviq> exec_with_ssh "cd $CODE_DIR/ && ./run $ARGS -- $RUN_OPTIONS"
[13:33] <Saviq> I can add '&& echo \${QML2_IMPORT_PATH}'
[13:33] <Saviq> and it's there
[13:33] <mzanetti> Saviq: right... forgot to escape the $
[13:34] <mzanetti> then it's there
[13:34] <Saviq> mzanetti, right, what I though
[13:34] <Saviq> t
[13:35] <Saviq> mzanetti, it's the ./run that doesn't get it somehow
[13:37] <Saviq> wtf ;?
[13:37] <mzanetti> +1
[13:44] <mzanetti> Saviq: well, it loads the environment but doesn't export it
[13:45] <Saviq> mzanetti, right
[13:51] <Saviq> mzanetti, thing is the whole sudo/bash atrocity should not be needed
[13:51] <Saviq> mzanetti, if I go
[13:51] <mzanetti> Saviq: that's what I would have said too. but ubuntu is behaving a bit different than the other distros I know
[13:52] <Saviq> ssh phablet@mako 'cd ~phablet/shell; ./run'
[13:52] <mzanetti> so I wasn't entirely sure
[13:52] <Saviq> that works fine
[13:52] <Saviq> mzanetti, but then if I make exec_with_ssh like that, it fails for some reason :/
[13:54] <Saviq> ah wait
[13:54] <Saviq> grrr no, without bash we don't have the whole env from upstart
[13:55] <mzanetti> Saviq: I guess ogra would be the right one to help here
[13:55] <Saviq> mzanetti, yeah, was about to go to him, wanted to try a few things
[13:57] <tsdgeos> Mirv: RC packages \o/
[14:07] <Mirv> tsdgeos: \o/
[14:21] <tsdgeos> Mirv: can we close this one down since we're not aiming at 5.1.1 anymore? or do these still fail under 5.2?¿
[14:35] <dandrader> tsdgeos, could you review my MP then?
[14:35] <greyback> tsdgeos: cool, can you link me to the gerrit page of that?
[14:35] <tsdgeos> dandrader: shoot the url
[14:36] <dandrader> tsdgeos, https://code.launchpad.net/~dandrader/unity8/runningAppsEndClose/+merge/196257
[14:36] <tsdgeos> greyback: https://bugreports.qt-project.org/browse/QTBUG-30493
[14:36] <mzanetti> Cimi: what do you think about this? https://bugs.launchpad.net/ubuntu-ux/+bug/1255926
[14:37] <Cimi> I know I'll miss those lazy days next week :)))
[14:37] <mzanetti> Cimi: yeah... thought the same :D
[14:37] <Cimi> mzanetti, ok I'll look at it
[14:38] <greyback> tsdgeos: no I meant the gles & opengl patch
[14:38] <tsdgeos> greyback: silly me i copied pasted from the wrong tab
[14:38] <tsdgeos> greyback: https://codereview.qt-project.org/#q,71717,n,z
[14:38] <greyback> tsdgeos: perfect, thanks
[14:40] <mzanetti> Cimi: https://bugs.launchpad.net/unity8/+bug/1255926/comments/2
[14:44] <MacSlow> Is the run_on_device script meant to work for the N10 at the moment?
[14:44] <Saviq> mzanetti, pushed the . /etc/environment to https://code.launchpad.net/~saviq/unity8/tweak-run-scripts/+merge/196871
[14:47] <mzanetti> Saviq: me... if I print the engine's importPathList it's still not there
[14:47] <mzanetti> +h :D
[14:47] <Saviq> mzanetti, yeah, I'll track that down - at least it's there in the run script ;)
[14:47] <mzanetti> indeed
[14:48] <Saviq> mzanetti, prolly not exported
[14:48] <mzanetti> yeah... same issue, one level down :D
[14:48] <Saviq> mzanetti, yup
[14:49] <Saviq> mzanetti, pushed
[14:50] <mzanetti> Saviq: \o/
[14:51] <Saviq> mzanetti, as for the whole thing - http://paste.ubuntu.com/6489818/
[14:51] <Saviq> mzanetti, that's what's there
[14:51] <Saviq> mzanetti, it's just the Unity.Application plugin in surfaceflinger + mir versions
[14:51] <mzanetti> Saviq: yeah, seen that...I'm actually a bit confused by the splitting of QT_INSTALL_QML and QT_INSTALL_IMPORTS
[14:51] <mzanetti> Saviq: in Qt4 there was only QT_INSTALL_IMPORTS and everything in there
[14:52] <mzanetti> it was named slightly different iirc
[14:52] <Saviq> mzanetti, yeah, I don't know of anything that's supposed to go into imports
[14:52] <Saviq> tsdgeos, ↑ do you?
[14:53] <tsdgeos> nope
[14:54] <mzanetti> Saviq: shouldn't we export whole environment instead of just that one variable?
[14:54] <Saviq> mzanetti, nah, everything that *should* be there is already there
[14:54] <mzanetti> ok
[14:54] <Saviq> mzanetti, i.e. everything else comes from /etc/profile and friends
[14:54] <Saviq> greyback, on that note, why does libunity-mir1 have all the symlinks? sounds like it's built like a shared lib instead of plugin?
[14:55] <Saviq> greyback, there's nothing that links against it is there?
[14:55] <greyback> Saviq: part of it is a shared lib
[14:55] <greyback> Saviq: the QML plugin links against it
[14:56] <Saviq> greyback, installed with the QML plugin?
[14:56] <greyback> Saviq: yes
[14:56] <Saviq> greyback, I mean http://paste.ubuntu.com/6489818/
[14:56] <greyback> Saviq: oh, I see. Yeah that's not necessary
[14:56] <karni> Can you guys help me install qmake on Ubuntu phone? would I install qt5-default if I want to compile a scope?
[14:56] <karni> root@ubuntu-phablet:/home/phablet/scope# qmake
[14:56] <karni> qmake: could not find a Qt installation of ''
[14:57] <Saviq> karni, or export QT_SELECT=qt5
[14:57] <greyback> karni: have you qt5-qmake installed?
[14:57] <Saviq> greyback, that's qtchooser complaining about not knowing which version to look for
[14:57] <mzanetti> Saviq: actually this seems a new issue too. installing qt5-default shouldn't require you to export QT_SELECT
[14:57] <Saviq> greyback, not that it can't find it
[14:57] <Saviq> mzanetti, yes, but karni said he doesn't have it installed
[14:57] <karni> I have qt5-default installed
[14:58] <Saviq> karni, oh
[14:58] <karni> I just reinstalled it
[14:58] <Saviq> ok /me misunderstood
[14:58] <mzanetti> Saviq: I noticed this too a few days ago
[14:58] <mzanetti> Saviq: my run_on_device_scripts from my apps stopped working
[14:58] <karni> Saviq: no, you were actually right, I just reflashed the device and tried again without it
[14:58] <karni> now I installed it, exported QT_SELECT=qt5 aaand.. make: /usr/lib/x86_64-linux-gnu/qt5/bin/qmake: Command not found
[14:59] <mzanetti> karni qt5base-dev etc installed?
[14:59] <Saviq> karni, yeah, that'd be qt5-qmake not installed
[14:59] <karni> mzanetti: will check
[14:59] <Saviq> karni, btw, scope? scope with qmake?
[14:59] <karni> E: Unable to locate package qt5base-dev
[15:00] <Saviq> karni, is there debian/control?
[15:00] <Saviq> karni, apt-get install devscripts equivs
[15:00] <karni> oh wait, I think I have the Makefile from my PC
[15:00]  * karni recreates that
[15:00] <Saviq> karni, yeah, saw x86_64 there
[15:01] <karni> Saviq: you got it. installing devscripts and equivs.
[15:01] <karni> Thanks guys
[15:01] <karni> First time I'm trying to actually compile a scope on the phone.
[15:01] <Saviq> karni, mk-build-deps -s sudo -i will install the build deps for a local package (assuming you've got debian/control there)
[15:02] <karni> On that note, need to tell Daniel H. (Cc mhall119 ) that we have a scope tutorial, but we don't have a scope tutorial for the phone, explicitly. It's the same code, but you do need some initial setup.
[15:02] <karni> Saviq: yeah, that's just a bare scope code, so no debian/control
[15:02] <karni> but I'll note that down :)
[15:07] <Saviq> greyback, bug #1256014
[15:08] <greyback> Saviq: ta
[15:08] <Saviq> MacSlow, greyback, ricmm, bug #1256011 too
[15:08] <Saviq> MacSlow, you just got hit 'cause Satoris isn't here ;)
[15:09] <MacSlow> Saviq, ah ok :)
[15:09] <Saviq> MacSlow, should be an easy fix, too
[15:11] <MacSlow> Saviq, will look into it
[15:17] <tsdgeos> can't run apps?¿
[15:20] <tsdgeos> Saviq: ↑↑ ?
[15:20] <Saviq> tsdgeos, try on console:
[15:21] <Saviq> upstart-app-launch webbrowser-app
[15:25] <tsdgeos> Saviq: nope
[15:25] <Saviq> tsdgeos, output?
[15:25] <tsdgeos> none :D
[15:26] <tsdgeos> phablet@ubuntu-phablet:~$ upstart-app-launch webbrowser-app
[15:26] <tsdgeos> phablet@ubuntu-phablet:~$
[15:26] <Saviq> tsdgeos, anything interesting in .cache/upstart/unity8.log ?
[15:26] <tsdgeos> only osk stuff
[15:26] <tsdgeos> maybe i should merge dandrader's branch before running
[15:26] <tsdgeos> let me see if that helps
[15:26] <tsdgeos> i mean merge with trunk
[15:27] <Saviq> tsdgeos, one more interersting place to look
[15:27] <Saviq> -r
[15:27] <Saviq> tsdgeos, .cache/upstart/application-foo.log
[15:27] <Saviq> where foo is the app name / app_id
[15:28] <tsdgeos> ok, will heck after merge/recompile/run finishes
[15:33] <tsdgeos> Saviq: hmmm, it indeed seems to be running
[15:33] <tsdgeos> it's just not on the screen nor on the currently running apps :D
[15:34] <Saviq> tsdgeos, and that's across unity8 runs?
[15:34] <Saviq> tsdgeos, weird... stock unity8, too? rebooted?
[15:34] <tsdgeos> that's when running dandrader|lunch's branch
[15:34] <tsdgeos> let me try the stock one
[15:37] <tsdgeos> stock one does actually work
[15:38] <tsdgeos> silly me for not having tried that
[15:38] <tsdgeos> sorry
[15:41] <tsdgeos> and now it works on dandrader's one too
[15:41]  * tsdgeos confused
[15:47] <mhr3> sil2100, anything blocking unity-scopes-api?
[15:48] <mzanetti> mhr3: hey, looking into scope.cpp, I see that you are trying to find a desktopFile for some "uri". where does this uri come from?
[15:49] <mhr3> mzanetti, scopes
[15:49] <mhr3> :)
[15:49] <mzanetti> mhr3: can we have activateApplication to pass the appId instead of the path?
[15:49] <mhr3> i know that was unexpected, right? :)
[15:49] <sil2100> mhr3: hi! I guess we just need someone to NEW it now, since it's in the queue - we'll be poking people soon
[15:49] <mzanetti> mhr3: we have quite some workarounds spread around to trim that down to an appId again
[15:50] <mhr3> mzanetti, iirc the uri format you expect isn't the same as what the scopes provide
[15:51] <mzanetti> mhr3: well, we expect the appId. not really an uri format
[15:51] <mhr3> see? :)
[15:51] <mzanetti> still doesn't answer my question. can we haz appIds there?
[15:52] <mhr3> what are appIds in your part of the code?
[15:52] <mzanetti> "address-book-app" for example
[15:53] <mzanetti> mhr3: we have a discussion ongoing to drop this version stuff from click's appId's too
[15:54] <mhr3> address-book-app doesn't sound overly unique to me
[15:55] <mhr3> shouldn't it have like full publisher name and stuff?
[15:56] <mzanetti> mhr3: yeah. click apps still have com.foo.bar.appname
[15:57] <mzanetti> mhr3: but stuff installed with apt doesn't
[15:57] <mhr3> mzanetti, iirc there's the appid schema-ed uri, imo we should use those
[15:57] <mzanetti> mhr3: tbh I don't really mind. but we used the appIds before that schema came up and now we have a mess of appId, url-schemas and full desktop file paths
[15:58] <mzanetti> so I'm trying to find where we could align that stuff
[15:58] <mhr3> mzanetti, i'm all for unifying it, just don't think we're there yet
[15:58] <Saviq> mhr3, there's also bug #1251635
[15:59] <mzanetti> obviously we're note there yet :) but I'm trying to get there :D
[16:01] <mzanetti> Saviq: IMO we should tackle this at the sprint together. greyback, you and me sitting down and fix that appId everywhere
[16:01] <mzanetti> do you think thats feasable?
[16:02] <greyback> mzanetti: yes let's make time to do that
[16:02] <mhr3> mzanetti, well clearly you do see what's involved, has to work for clicks, has to work for regular .desktop from apt, should be compatible with unity7 in some way
[16:02] <mhr3> mzanetti, once you have a solution, open bugs :)
[16:02] <greyback> mzanetti: Saviq: did we ever decide if we'd handle appIds with or without the version string?
[16:03] <mhr3> or push patches :)
[16:03] <mzanetti> greyback: I'm afraid we didn't get a response from the click people
[16:04] <greyback> mzanetti: was there a mail sent or something?
[16:04] <mzanetti> greyback: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1251635
[16:04] <mzanetti> the day when we reported it, the people I pinged were either at a conference or in holidays
[16:04] <mzanetti> let me try again
[16:05] <mzanetti> ah.. today US is not around either
[16:05] <greyback> oh darn
[16:06] <greyback> cjwatson is online
[16:06] <greyback> mzanetti: ^^
[16:07] <Saviq> greyback, doesn't mean he's responsive
[16:07] <greyback> oh not for a while
[16:07] <Saviq> greyback, he did send an email that he's gone
[16:07] <greyback> Saviq: ah ok
[16:07] <Saviq> greyback, mzanetti FWIW internally we should go no-version-string
[16:08] <mzanetti> agreed
[16:08] <greyback> +1
[16:08] <mzanetti> but then there is still the full desktop path coming from the scopes
[16:08] <mzanetti> and some places where we expect or get application://
[16:08] <Saviq> greyback, mzanetti it should be stripped as soon as it reaches us, and re-introduced when going out
[16:08] <mzanetti> it's close to impossible to change something in Stage.qml without breaking something
[16:08] <Saviq> mzanetti, basename minus extension?
[16:09] <mzanetti> Saviq: would you do that in scope.cpp or when it reaches us on the QML side?
[16:09] <Saviq> mzanetti, we just need to normalize to ".desktop file name minus extension, minus version"
[16:09] <Saviq> mzanetti, cpp
[16:09] <mzanetti> ok... good
[16:09] <Saviq> mzanetti, basically as close to process boundary as possible
[16:13] <mzanetti> do we have some easy ./run method now with scopes in their own repo?
[16:13] <Saviq> mzanetti, same
[16:13] <Saviq> mzanetti, ./build -s will install them
[16:14] <Saviq> mzanetti, and then they're picked up automagically
[16:16] <mzanetti> Saviq: I'm feeling stupid. but can't find anything like that
[16:16] <Saviq> mzanetti, hmm?
[16:17] <mzanetti> Saviq: unity8's ./build -s doesn't do anything like that
[16:17] <Saviq> mzanetti, the package us unity-plugin-scopes
[16:17] <Saviq> is
[16:17] <mzanetti> Saviq: ah. so you mean it will be installed with apt
[16:17] <Saviq> mzanetti, yes
[16:17] <mzanetti> I meant a ./run if I want to change the code in there
[16:17] <Saviq> mzanetti, just export QML2_IMPORT_PATH
[16:18] <Saviq> mzanetti, with my branch that is
[16:18] <mzanetti> ok
[16:18] <Saviq> mzanetti, anything you export before run
[16:18] <Saviq> mzanetti, will be the first fallback
[16:18] <mzanetti> ok. cool
[16:18] <Saviq> mzanetti, so builddir/plugins is first, then QML2_IMPORT_PATH, then mocks
[16:36] <Saviq> tsdgeos, ping
[16:36] <tsdgeos> Saviq: yes?
[16:42] <mzanetti> mhr3: https://code.launchpad.net/~mzanetti/unity-scopes-shell/activate-appid/+merge/197098
[16:44] <mhr3> mzanetti, doesn't handle the full path case
[16:45] <mzanetti> mhr3: no?
[16:45] <Saviq> mzanetti, thank you ;D
[16:45] <mzanetti> ah wait...
[16:45] <mzanetti> Saviq: ?
[16:45] <Saviq> mzanetti, I wanted to get rid of that chunk of code a long time ago ;)
[16:45] <Saviq> mzanetti, there's too much g_ ;D
[16:45] <mhr3> noone like gio, snip :P
[16:45]  * mzanetti is always happy to remove g_'s
[16:46] <mhr3> evil, evil people!
[16:46] <Saviq> g_free *shrug*
[16:48] <mhr3> noone shrugs at g_free
[16:48] <mhr3> g_free is awesome!
[16:48] <mhr3> cause it does if(ptr) free(ptr)
[16:49] <mhr3> clearly that's the best function since sliced bread... i mean vmsplice?
[16:53] <mzanetti> mhr3: better now?
[16:54] <mhr3> mzanetti, /usr/share/applications/kde4/kate.desktop will give you "kate", are you sure that's enough?
[16:55] <mzanetti> hmm... fair point.
[16:56] <mzanetti> I think those are handled as kde4-kate
[16:56] <mhr3> usually, yes
[17:07] <mzanetti> mhr3: actually... can there be something like application:///usr/share/applications/kde4/kate.desktop ?
[17:07] <mzanetti> I mean the full path + application uri schema
[17:07] <mhr3> yes
[17:08] <mhr3> it's the same as application://kde4-kate.desktop but both are valid
[17:08] <mzanetti> yay for yet another combination :) I thought application has to be appid
[17:08] <mhr3> it's for resolving ambiguities iirc
[17:08] <mhr3> ie if you have foo.desktop in both /usr/share/applications and in ~/.local/share/applications
[17:12] <mzanetti> pushed another version
[17:13] <mhr3> hardcoding paths?
[17:13] <mhr3> eeeek! :P