[13:15] <boghison> Hi! Can I ask questions about scopes here?
[13:18] <Saviq> boghison, sure, note that today is a public holiday in a lot of places though
[13:19] <boghison> Saviq: Are you willing to help? :)
[13:19] <Saviq> boghison, I'm willing to try :)
[13:20] <boghison> Saviq: OK, thanks :) I need to learn more about the scope runtime system, specifically how scopes are started. I am writing bindings for Rust and can't start my scope
[13:20] <Saviq> it's best to just ask, if someone knowledgeable comes around, they'll try and answer
[13:20] <Saviq> boghison, and this is about the new scopes system for the Ubuntu Phone, right?
[13:21] <boghison> Saviq: Yes, but also about the scope tool for the desktop
[13:21] <Saviq> sure, that's the same thing
[13:21] <Saviq> you probbaly saw this, but for completeness https://developer.ubuntu.com/api/devel/ubuntu-14.10/cplusplus/unity-scopes/
[13:22] <boghison> yes, of course, that's what I am researching, specifically the Runtime class
[13:22] <Saviq> boghison, the scope registry is a long-running process in the user session that starts the queried scopes on demand
[13:23] <Saviq> it starts them via the scope runner, which loads the scope's shared object file and starts the machine rolling
[13:23] <boghison> Saviq: Yes, but there's a difference with Rust (and Go for that matter, which has bindings for the scopes api)
[13:23] <boghison> There's no .so
[13:23] <boghison> It's the app that has to start
[13:23] <boghison> and the ini file has a field for that
[13:24] <Saviq> yeah, they need a different runner (or a custom binary altogether)
[13:24] <boghison> Yes, the Runtime class is used
[13:25] <boghison> the problem is that the scope tool doesn't see my scope and just searches for something generic, therefore providing me with this Unable to add overview scope, can't find with ID: "scopes"
[13:26] <Saviq> that's actually a non-fatal warning
[13:27] <Saviq> "scopes" is what's responsible for the "Manage dash" page that you can reach by a bottom swipe on the phone
[13:27] <boghison> Any idea why the scope doesn't start then
[13:27] <boghison> It gives me some timing errors as well
[13:27] <Saviq> have you checked the scope registry logs in ~/.cache/upstart/?
[13:28] <Saviq> is the registry even started? (that could explain the timeout errors)
[13:28] <Saviq> i.e. `initctl status scope-registry`?
[13:28] <Saviq> I'm afraid this is the extent of my knowledge there, you might need to wait until next week when some of the guys that know more about that part of the system are around
[13:29] <Saviq> I think jamesh__ wrote the Go bindings, so he might help if around
[13:29] <boghison> Saviq: C++ scopes work fine
[13:29] <boghison> what file do I have to look for in the logs?
[13:29] <Saviq> scope-registry.log
[13:29] <boghison> there's no such file
[13:29] <Saviq> that's the upstart session job responsible for keeping the registry going
[13:30] <Saviq> might be that it didn't log anything
[13:30] <boghison> Hmm, there are mostly gzipped files
[13:30] <Saviq> those are rotated logs from before
[13:31] <boghison> there's this: update-notifier-crash-_var_crash__usr_lib_x86_64-linux-gnu_unity-scopes_scoperunner.1000.crash.log.7.gz
[13:31] <Saviq> that's likely unrelated
[13:32] <boghison> :(
[13:32] <Saviq> ah
[13:33] <Saviq> https://launchpad.net/go-unityscopes here's the relevant project for go, but I imagine you've seen that already
[13:33] <boghison> Yes, I have, the most important files are shim.* and unityscopes.go
[13:33] <boghison> But I am mostly doing the same
[13:33] <boghison> And it still doesn't work
[13:33] <Saviq> how are you starting the tool btw? are you passing the scope id to the tool, or letting it list you all the scopes?
[13:34] <boghison> I am doing unity-scope-tool inifile.ini
[13:34] <boghison> which has this field
[13:34] <boghison> ScopeRunner=./rust-test --runtime %R --scope %S
[13:35] <boghison> although those flags don't do much
[13:35] <boghison> actually, I wanted to tell you
[13:35] <boghison> the binary doesn't start
[13:35] <boghison> in the main function I log all the arguments
[13:35] <boghison> and nothing gets printed to the console
[13:36] <Saviq> I'm not sure, but stdout should be redirected to the scope-registry.log file
[13:37] <Saviq> when it is started, it's started as a child of the registry, so stdout you get from the test tool is only coming from QML and the plugin from lp:unity-scopes-shell
[13:38] <Saviq> hmm or wait, I think if you pass the .ini file, the tool actually creates a custom internal registry
[13:39] <Saviq> so whether the session-wide one runs or not is irrelevant, and I'm not sure where stdout goes...
[13:39] <boghison> :(
[13:39] <Saviq> you could try printing to a file instead of stdout to confirm it's not being run
[13:39] <boghison> printing what
[13:39] <boghison> if I redirect the output
[13:40] <boghison> it's just gonna be the scope runner's output
[13:40] <boghison> no?
[13:40] <Saviq> no, I mean in your scope runner
[13:40] <Saviq> print to a file
[13:40] <Saviq> instead of to stdout
[13:40] <boghison> you mean in the binary?
[13:40] <Saviq> in your Rust code
[13:41] <boghison> oh, ok
[13:41] <Saviq> because I'm not sure if stdout from it would ever get printed anywhere
[13:41] <boghison> this is gonna take a while
[13:43] <Saviq> I'm afraid that's as far as I can take you anyway, you'll need to come back when more of my colleagues are online (Tuesday morning AU time probably)
[13:47] <boghison> but it did print to the file
[13:48] <boghison> at least that is working
[13:51] <Saviq> \o/
[13:52] <boghison> I am going to try hacking a bit more
[13:52] <boghison> Thanks for your idea
[13:52] <boghison> :)
[14:18] <Saviq> mterry, hey, you working today?
[14:18] <Saviq> mterry, hey, you working today?
[14:19] <mterry> Saviq, yes, just slow start to it
[14:19] <Saviq> mterry, can you resubmit one of your tutorial branches on the other
[14:19] <Saviq> mterry, they're conflicting
[14:19] <mterry> Saviq, oh sure, didn't realize I had overlapped
[14:19] <Saviq> mterry, for reference https://ci-train.ubuntu.com/job/ubuntu-landing-025-1-build/51/console
[14:21] <Saviq> mterry, Josh touched qml/Shell.qml, too, but I'd say there's chance the two tutorial-related ones are the culprit
[14:21] <mterry> Saviq, yup, i get a conflict
[14:21] <Saviq> t
[14:21] <Saviq> x
[14:22] <greyback> Saviq: any word on a landing strategy while FF in effect?
[14:22] <Saviq> greyback, FF well past, we're in Beta Freeze now
[14:23] <Saviq> greyback, anyway, I'm still hoping for a global PPA to land into
[14:23] <greyback> Saviq: well freeze
[14:23] <Saviq> your well froze?
[14:23] <greyback> sounds like by the time it might be ready, we'll be on w-release
[14:24] <Saviq> greyback, sil2100 is still thinking whether a complete derived archive would be better, if anything will happen, earliest next week
[14:24] <Saviq> hopefully we'd have a ready-made strategy for next time
[14:24] <mterry> Saviq, done
[14:24] <Saviq> mterry, tx
[14:24] <sil2100> Yeah, although I seem to be leaning towards the PPA option
[14:25] <sil2100> Just need to confirm the train codwe
[14:25] <sil2100> *code
[14:26] <Saviq> in theory this should be just another upload target for publishing
[14:26] <Saviq> the problematic bits is probably migration and publish monitoring
[14:29] <sil2100> This part of the train worked fine in the past, but not sure now as we didn't use it for ages
[15:05] <greyback> mterry: in summary, I think your fix will do for now.
[15:05] <mterry> greyback, fair enough
[15:11] <mterry> greyback, "Note, the mirserver QPA does not have this "eglcontext" native resource exported. That may cause issues" -- is that an issue with ubuntumirclient too or specific to unity8's use of "mirserver"
[15:11] <mterry> ?
[15:12] <greyback> mterry: just mirserver
[15:12] <mterry> greyback, ok will adjust patch then
[15:13] <greyback> mterry: *may* - you tested it, it'll probably be ok
[15:13] <mterry> greyback, haven't tested it yet!  :)  I'm building my patch as we speak
[15:13] <mterry> greyback, took me forever to find a way to build it that didn't die on me
[15:13] <mterry> greyback, can't do it on tiny phones
[15:13] <greyback> ah ok. well the code checks if it gets a shared context back or not, so it shouldn't break anything
[15:14] <mterry> greyback, ok cool
[15:14] <greyback> mterry: does it cross compile in sbuild?
[15:14] <mterry> greyback, I'm testing it in pbuilder
[15:14] <mterry> greyback, we'll see
[15:14] <greyback> ok
[15:14] <mterry> greyback, I was hoping jenkins would do it overnight, but no luck
[15:14] <greyback> ouch
[15:17] <mterry> greyback, you say the fix isn't future proof.  Do we have a smarter fix we can implement now, or are you just saying "we know we'll have to come back and edit this in the future"
[15:17] <greyback> mterry: sadly I don't
[15:17] <mterry> greyback, cool
[15:17] <mterry> well, cool isn't right word  :)
[15:17] <greyback> I've not come up with a reliable way to figure out if qt compiled at runtime with gl or gles
[15:20] <mterry> greyback, I agree that qt should totally already expose that
[15:43] <Trevinho> greyback: hey, I've reproposed your branch https://code.launchpad.net/~3v1n0/unity/switcher-first-selection-mode/+merge/255195, so give it a look please...
[15:44] <greyback> Trevinho: ah sweet, I totally forgot about that