[08:23] <alan_g> duflu: any thoughts on the right way to handle the libmirclient deprecations for 16.04? Reworking all the downstreams to use the new APIs seems like risky behaviour.
[08:30] <duflu> alan_g: No immediate thoughts :P
[08:30] <duflu> :/  I mean
[08:34] <alan_g> :)
[13:05] <xnox> hi, is there anybody who could advise me on qtmir and qtmir-gles
[13:05] <xnox> are they going to be supported, developed and needed in artful and going forward?
[13:05] <xnox> e.g. does kiosk use it?
[13:06] <alan_g> xnox: the kiosk doesn't use it
[13:07] <xnox> alan_g, thanks. what about maintainance and supporting qtmir in artful? no idea?
[13:10] <alan_g> I can't give a definitive answer to that yet. But it isn't needed for IoT, so I don't forsee any active development
[13:12] <alan_g> xnox: what usecase interest you?
[13:15] <xnox> alan_g, i am interested to drop src:upstart, src:cgmanger, src:libnih from artful. And currently src:qtmir[-gles] depend on cgmanager libraries. I'm pondering if i need to touch/fix that
[13:15] <xnox> or src:qtmir can simply be removed from artful
[13:17] <alan_g> Saviq: can you give a better answer? ^^
[13:18] <Saviq> xnox, remove it, if we find that we need it, we'll revisit
[13:21] <xnox> hm, that would mean removing src:unity8 and e.g. src:ubuntu-push
[13:21] <xnox> but i thought ubuntu-push will be in snappy, no?
[13:21] <xnox> or was ubuntu-push phone/touchy stuff?
[13:24] <xnox> alan_g, Saviq - so ubuntu-app-launch has moved onto systemd, yet qtmir is using cgmanager/upstart cgroup paths to determine related app pids
[13:24] <xnox> so my understanding is that fetchAssociatedPids is now broken.
[13:24] <xnox> and effectively always returns "which is not app-specific"
[13:24] <xnox> (e.g. does not find any related pids)
[13:25] <Saviq> that might very well be, greyback ↑ ?
[13:25] <alan_g> greyback: ^^
[13:26] <xnox> QSet<pid_t> DBusFocusInfo::fetchAssociatedPids(pid_t pid) always goes down the else path, as no things in zesty+ have 'upstart' in their cgroup
[13:28] <greyback> xnox: I think you're right yes. However that code is only used to expose a pid list via dbus of focused apps, which is used only by autopilot I think.
[13:29] <xnox> aha
[13:29] <greyback> it is not important code, and we didn't notice this bug in the systemd transition
[13:30] <greyback> because almost nobody uses that dbus api
[13:30] <xnox> greyback, i think i will make the code to go down the else path, without changing any api/abi
[13:30] <xnox> and drop build-dep and runtime dep on the cgmanager.
[13:30] <xnox> meaning i'm not making things any worse.
[13:30] <xnox> it is possible that autopilot uses ubuntu-app-launch apis directly for the systemd code path =/
[13:31] <greyback> xnox: I think that change won't hurt anyone that we care about
[14:11] <xnox> running tests now, fingers crossed
[14:12] <xnox> horay!
[14:13] <xnox> onto gles variant
[14:37] <xnox> greyback, i've asked tedg if there is anyway to get all the pids from ubuntu-app-launch and here is his response
 xnox: Yup, you can grab it from the instance object, pids() returns a vector.
 xnox: You can also call ubuntu-app-launch-pids
 nice.
 xnox: But those will only really work on U8...
[14:38] <xnox> so either autopilot should use that, or qtmir should re-expose that over db
[14:41] <greyback> xnox: right. UAL does make that possible, we just kept neglecting that particular bit of code
[14:42] <xnox> ah, ok.
[14:42] <xnox> i shall open a bug report.
[14:42] <xnox> at least