[08:39]  * guest42315 they see me rollin' la la la
[14:00] <Saviq> ltinkl, can you rebase betterDesktopIndicators on Albert's clazy_run branch, there's a conflict between the two
[14:00] <ltinkl> Saviq, sure
[14:01] <ltinkl> Saviq, lp:~aacid/unity8/clazy_run ?
[14:01] <Saviq> ltinkl, yup
[14:01] <ltinkl> k, on it
[14:03] <ltinkl> Saviq, done
[14:05] <Saviq> ltinkl, you also need to repropose the MP with the prerequisite field filled
[14:05] <ltinkl> Saviq, ok
[14:06] <Saviq> ltinkl, https://code.launchpad.net/~lukas-kde/unity8/betterDesktopIndicators/+merge/271455/+resubmit
[14:06] <ltinkl> Saviq, https://code.launchpad.net/~lukas-kde/unity8/betterDesktopIndicators/+merge/272251
[14:07] <Saviq> tx
[14:09] <ltinkl> Saviq, in the fixLogin1Tests branch, I'll add a few more tests to cover also the gnome screensaver interface, ok? I can mock that too
[14:09] <ltinkl> Saviq, those were missing previously
[14:10] <Saviq> ltinkl, having browsed through the two commits, two things stood up: maybe use ::invokeMethod to avoid all the if/elses?
[14:11] <ltinkl> Saviq, right ye... I was trying to add a QFunctionPointer to  QTest::newRow() but this is better :))
[14:11] <ltinkl> Saviq, and it didn't work anyway
[14:12] <Saviq> ltinkl, and you need to cover the opposite case as well, with how it's there you test that Can* return just one value, you need to make the mock return all the four expected values (no, na, yes, challenge) and verify the returned value is correct
[14:12] <ltinkl> Saviq, ok
[14:15] <Saviq> because with how it is today you don't even know what it returned
[14:16] <Saviq> ltinkl, ah and also, maybe use dbus-test-runner's task management capabilities instead of spawning it in the test? although that I'm not hung up on
[14:17] <ltinkl> Saviq, that I tried and the test runner refuses the python mock to connect to it
[14:19] <Saviq> ltinkl, d'oh, just noticed --bus-type in dbus-test-runner's help ;)
[14:19] <ltinkl> Saviq, ye I know that one, tried
[14:21] <Saviq> ok we'll need to revisit our usage of it then
[14:32] <ltinkl> Saviq, about the repetitive test with different values, do you think that's necessary? I'm currently testing if the return value from our DUSS service actually matches the one returned by logind
[14:33] <Saviq> ltinkl, but you don't test what happens if logind returns something different
[14:33] <ltinkl> Saviq, so it's also covering the "no" and "na" cases, the left side is boolean
[14:33] <ltinkl> Saviq, hm
[14:33] <Saviq> ltinkl, what I mean
[14:33] <Saviq> ltinkl, is that during the test, it only returns one value, that you don't even know
[14:34] <Saviq> ltinkl, you need to make the mock return all cases to the call made by DUSS
[14:34] <Saviq> and verify the other end is correct
[14:34] <Saviq> ltinkl, btw,
[14:34] <Saviq> dbus-test-runner --task python --ignore-return --parameter -m --parameter dbusmock --parameter org.freedesktop.login1 --parameter /org/freedesktop/login1 --parameter org.freedesktop.login1.Manager --task builddir/tests/plugins/Unity/Session/sessionbackendtestExec --wait-for org.freedesktop.login1
[14:34] <ltinkl> Saviq, ye but the code expects "yes" or "challenge" so if anything else comes our way, false is returned
[14:36] <Saviq> dednick, standup?
[14:37] <ltinkl> Saviq, cool cmd line, that works for me, thanks :)
[14:44] <pstolowski> mzanetti, hey, are you ok if i propose debian/post{inst,rm} for unity8 similar to the ones shown in the description of this bug: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1389257 ?
[14:52] <ltinkl> Saviq, here are the builtin templates that we might want to use throughout our tests: https://github.com/martinpitt/python-dbusmock/tree/master/dbusmock/templates
[14:56] <mzanetti> pstolowski, sounds reasonable
[14:57] <mzanetti> pstolowski, isn't there anothe method to get the version at runtime?
[14:57] <mzanetti> it does seem a bit of a hack with those files
[15:02] <cimi> mzanetti, hey ho, welcome back
[15:02] <mzanetti> hi cimi ;)
[15:02] <cimi> mzanetti, just a quick thing, was talking to pstolowski about adding a property also for the content type
[15:03] <cimi> mzanetti, I cannot detect the content type from the dash for remote url
[15:04] <mzanetti> hmm... I see
[15:04] <mzanetti> cimi, actually... no
[15:04] <mzanetti> if it's a remote, contenttype is ContentTyle.Link
[15:04] <cimi> mzanetti, what about is a remote mp3 stream?
[15:05] <cimi> mzanetti, or a remote picture?
[15:05] <mzanetti> still a link, no?
[15:05] <mzanetti> if you set it to ContentType.Picutre, contenthub will expect a file
[15:05] <cimi> :/
[15:05] <mzanetti> and it wants to copy/hardlink the file
[15:05] <cimi> mzanetti, so if I want to stream a mp3?
[15:05] <Saviq> ltinkl, oh cool so there's a logind template already
[15:05] <cimi> mzanetti, and open with the streamer
[15:06] <mzanetti> cimi, well, the music app should support receiving contentTyle.Link
[15:06] <mzanetti> and then just start playing it
[15:07] <Saviq> ltinkl, so with something like
[15:08] <Saviq> dbus-test-runner --bus-type=both --task python --parameter -m --parameter dbusmock --parameter -t --parameter logind --ignore-return --task builddir/tests/plugins/Unity/Session/sessionbackendtestExec --wait-for org.freedesktop.login1
[15:08] <Saviq> ltinkl, that actually makes the trunk test pass for me
[15:09] <cimi> mzanetti, :/
[15:10] <cimi> mzanetti, partly convinced
[15:10] <Saviq> now you only need to control the mock to return the right values
[15:11] <mzanetti> cimi, I just asked ken:
 kenvandine, hey, if we want to share a remote music stream, that's ContentType.Link, right? Not Music
 yeah
[15:11] <Saviq> that sounds wrong
[15:12] <mzanetti> the thing is, when you share something !Link and !Text, ContentHub will want to manage the file
[15:12] <mzanetti> copy it into the target app's folders etc
[15:12] <Saviq> well, sure, but that's wrong
[15:13] <pstolowski> mzanetti, we were using dpkg-query before, but that's expensive (thus the bug report). another way would be to use a native apt api i guess... but that sounds like too much for what we need
[15:13] <mzanetti> mhm
[15:13] <Saviq> you want to share music, whether it's a local or remote file is a different question?
[15:14] <pstolowski> mzanetti, i'm also exploring the idea of abandoning the idea of collecting versions completely, and only send /etc/ubuntu-build number to smart scopes proxy
[15:14] <Saviq> mzanetti, OTOH, what if the target app can't do network... you could say content hub might need to download it first... which in a case of a stream might be problematic ;P
[15:14] <mzanetti> Saviq, right... I agree, I guess... but that's kinda out of scope for cimi's task :)
[15:14] <Saviq> true
[15:14] <mzanetti> Saviq, would require 2 props
[15:14] <Saviq> mzanetti, +1
[15:14] <mzanetti> pstolowski, I'm not really opposing it.... but I find it quite the opposite of an elegant solution
[15:15] <pstolowski> mzanetti, i know. but that was suggested by apt guru
[15:15] <pstolowski> if that helps you swallow it ;)
[15:16] <Saviq> yikes
[15:16] <mzanetti> pstolowski, that'd be my favorite... not exactly sure why you need the unity version number... but if we could get rid of that reverse-dep it'd be best IMO
[15:16] <pstolowski> mzanetti, reverse-dep? what do you mean?
[15:17] <mzanetti> pstolowski, that's the wrong word, I know...
[15:17] <pstolowski> mzanetti, we're currently collecting version numbers of scopes api, shell plugin and unity8 and send them with queries to smart scopes server. this was meant to help them implement workarounds for old clients etc.
[15:17] <mzanetti> I see
[15:17] <pstolowski> mzanetti, i'm disccusing with them abandoning it and only send build number
[15:18] <mzanetti> pstolowski, ok, cool. if you can't manage to get there, feel free to add the proposed solution from the bug report... I won't block it
[15:18] <pstolowski> mzanetti, k, thanks
[15:23] <pstolowski> cimi, sorry, i had to read the backlog
[15:23] <pstolowski> cimi, what mzanetti says sounds reasonable, in that case content type doesn't make sense?
[15:24] <mzanetti> nope... doesn't make sense... well, for local content we need to figure the contentType... but giving remote uri's to content-hub and setting something else than ContentType.Link will break it
[15:24] <mzanetti> in its current incarnation at least
[15:24] <mzanetti> I also agree that this is not ideal
[15:25] <Saviq> pstolowski, don't smart scopes go away anyway? ;P
[15:25] <pstolowski> cimi, i think it would still make sense to make this sharable a dict, e.g. 'share': {'uri': ..} in case we need to add something in near future
[15:27] <pstolowski> Saviq, kind of... they are in maintenance mode only, no new remote scopes anymore, therefore my suggestion to drop these version numbers completely if they ack it. but i think we will need to live with these scopes for a while still...
[15:33] <cimi> pstolowski, ok