[01:54] <duflu> robert_ancell: I notice USC is started by lightdm. Is there a way I can give USC extra env vars?
[01:54] <duflu> ... on a phone
[01:54] <robert_ancell> duflu, the easiest way is to make a script and set lightdm to load that. I think the phone is already doing that
[01:55] <robert_ancell> i.e. /usr/sbin/unity-system-compositor is a shell script to /usr/sbin/unity-system-compositor.real
[01:55] <duflu> robert_ancell: Can you tell me where lightdm actually loads the thing called "unity-system-compositor"? I never found that bit
[01:56] <robert_ancell> duflu, what do you mean where, i.e. the code location or the configuration?
[01:56] <duflu> robert_ancell: Configuration. How does lightdm know it must start a system compositor and what it's called?
[01:57] <robert_ancell> duflu, the default is hard-coded to unity-system-compositor but it can be configured by setting unity-compositor-command in [Seat:*]
[01:57] <duflu> robert_ancell: Surprising but glad to see I never would have found it then. :)
[01:58] <robert_ancell> duflu, /usr/share/doc/lightdm/lightdm.conf.gz contains all the configuration options and their defaults
[01:59] <duflu> robert_ancell: Oh nice, thanks
[02:56] <duflu> RAOF: Could you refresh your MP(s), so we can confirm CI is happy with the completed transition?
[02:56] <duflu> Seems OK when I build things by hand
[02:57] <duflu> Oh, except cross compiling still fails
[03:05] <duflu> Maybe too early
[03:10] <duflu> Maybe not. Seems to just be a bug in the xcompile script. Fixing that now
[03:21] <RAOF> If Jenkins is building against proposed I think things should be working...
[03:22]  * RAOF presses the try again button.
[03:22] <RAOF> Although those previous builds look pretty ominous :)
[03:26] <duflu> RAOF: I suspect vivid builds are somehow broken now which might hold up CI. Discovered by: https://code.launchpad.net/~vanvugt/mir/xcompile-wily/+merge/268183
[03:27] <RAOF> Oh, hm.
[03:28] <duflu> Still haven't seen any fresh Jenkins runs this week
[03:28] <duflu> But should do within hours
[03:28] <RAOF> Yeah, that'd be the gcc-5 cross-compiler VS gcc-4.9 libstdc++ on wily.
[03:42] <RAOF> duflu: Have you tried running your crossbuilt packages on a mako?
[03:42] <duflu> RAOF: Nope
[03:43] <RAOF> I'm reasonably certain they'll fail, for roughly the same reason that they don't *build* if you use gcc-5 :)
[03:46] <duflu> RAOF: Even with devel-proposed on mako?
[03:46] <duflu> I'd have thought it should work
[03:47] <RAOF> I guess it depends on precisely how the jenkins makos are configured.
[04:34] <duflu> RAOF: Jenkins is back. And with more failures than ever. Seems in the least it's not using the latest archive contents yet on wily
[04:35] <RAOF> It quite possibly doesn't build against wily-proposed.
[04:35] <RAOF> Which is silly, but there you go.
[04:35] <RAOF> Where's our self-serve Jenkins? :)
[04:38] <duflu> RAOF: proposed is not required. Just the latest wily archive as of a few hours ago
[04:38] <RAOF> Ah, good.
[04:39]  * duflu wonders how far behind Jenkins lags the archive contents
[04:39] <RAOF> It shouldn't lag at all; it pulls the packages in at build-time.
[04:39] <duflu> Weird
[04:43] <RAOF> Hm. Is std::function<> not a standard layout type?
[04:43] <RAOF> How bothersome.
[08:07] <RAOF> Woot! And with that doing the vague thing it's meant to do, it's EOD.
[09:33] <duflu> Wow Mir has a lot of compositor implementations built in now. I find myself accidentally testing the wrong one
[09:38]  * alan_g sees another opportunity for the delete key
[09:41] <duflu> alan_g: Unfortunately they all exist for different reasons
[09:41] <alan_g> ;)
[10:49] <alan_g> greyback_: I'm just looking at qtmir again. cmake reports "--   package 'unity-shell-application=7' not found" - I don't see that package (in wily), is it specific to overlay?
[10:51] <greyback_> alan_g: yep. unity-api in wily is behind currently
[10:53] <alan_g> Thanks. I'll not expect it to work (for now).
[13:58] <kenvandine> kgunn, silo 0 was dirty so i kicked a rebuild, but it fails
[13:58] <kenvandine> Silo config is missing these packages: qtmir-gles
[13:59] <kenvandine> i was going to update my device this morning, but worried i'd end up with a unity8 that didn't work :)
[14:02] <kgunn> kenvandine: ah...i don't kick builds there since greyback_ has his ways :)
[14:03] <kenvandine> i don't know what causes the silo config error
[14:03] <kenvandine> maybe the silo was reconfigured or something?
[14:04] <kgunn> kenvandine: actually in that instance, you have to tick the box
[14:04] <kgunn> ignore missing gles twins
[14:04] <kenvandine> ah
[14:04] <kenvandine> mind if i do that?
[14:04] <kenvandine> so users of the silo don't get the wrong unity8 :)
[14:05] <kgunn> it's a weird sync thing to make gles/gl all happy on deskotp
[14:05] <kgunn> greyback_: ^ that ok ?
[14:05] <kgunn> to build a new unity8 ?
[14:13] <greyback_> kenvandine: please don't kick off builds in silo0, ask me first. Being dirty doens't mean it won't work, as citrain script pins the packages from that silo so they still install over the newer versions
[14:13] <kenvandine> ok
[20:53] <kenvandine> RAOF, my magic trackpad doesn't move the pointer, i think this branch might fix that
[20:53] <kenvandine> https://code.launchpad.net/~ken-vandine/mir/touchpad_pointer/+merge/268274
[20:54] <kenvandine> RAOF, but i haven't been able to build that for the device, so not tested :)
[20:54] <kenvandine> what do you think?
[23:35] <RAOF> kenvandine: My magic trackpad moves the pointer fine, in mir_demo_server?