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