[02:14] <kgunn> robert_ancell: did you want to land that silo 59 xmir ? or is that just for testing....
[02:14] <kgunn> i guess question is, are you gonna land that using the citrain ?
[02:14] <robert_ancell> kgunn, I'm waiting bregma and co to confirm it's really better before landing
[02:15] <kgunn> robert_ancell: we were just discussing
[02:15] <kgunn> robert_ancell: definitely better aiui
[02:15] <robert_ancell> kgunn, oh, I was expecting to use the CI train - but I've never got that far with a silo before
[02:15] <robert_ancell> Good
[02:16] <robert_ancell> The downside is we can't land it into wily, so it has to go through the CI train to get into the overlay PPA right?
[02:18] <bregma> I think the strategy need to be to branch so we can land in vivid+overlay while wily is frozen, then backport to "upstream" for X (ie. 16.04 X, not x.org X)
[02:18] <bregma> otherwise we're blocked
[02:19] <bregma> and there's a good chance we'll never ship a device with wily (jumping from vivid+overlay to 16.04 LTS + overlay)
[02:20] <robert_ancell> bregma, the package in the silo is a branched version - we'll update the XMir patch in x-series
[02:20] <bregma> anyway, robert_ancell, ChrisTownsend says silo 59 is much, much better (does not crash) but still has damaage problems, and I believe duflu has more bugfixes waiting to go in on top
[02:21] <bregma> landing silo 59 would be a good thing at this point
[02:21] <robert_ancell> bregma, ok, cool. So we should land that into the overlay PPA
[02:21] <robert_ancell> And do another silo when it's improved
[02:21] <duflu> Not more fixes in mind, but I have created three accurate-ish bug lists for Xmir
[02:21] <duflu> Lots of bugs remain
[02:26] <robert_ancell> Does anyone know the next step for this silo. Do I just click publish on https://requests.ci-train.ubuntu.com/#/ticket/405 or do I need to ask someone from the CI team.
[02:26] <robert_ancell> ?
[02:31] <bregma> robert_ancell, you need to change "No QA Needed" to "Publish without QA"
[02:32] <robert_ancell> bregma, ok, done. Do I then publish myself?
[02:33] <bregma> robert_ancell, I think so, robru sent an email last week about that, but it doesn;t hurt to ask on #ubuntu-ci-train for clarification
[02:34] <bregma> I seem to have deleted the email
[02:34] <robert_ancell> bregma, there's no-one in #ubuntu-ci-train it seems... What server?
[02:35] <robert_ancell> ah, #ubuntu-ci-eng
[03:07] <robert_ancell> bregma, kgunn, OK, it appears to be in the overlay PPA now
[05:13] <duflu> RAOF: Going for a diff record? :)
[05:13] <duflu> I see it's gone now
[05:13] <RAOF> Turns out when you have a full-file conflict with every file in the repository the diff is pretty big!
[05:28] <duflu> RAOF: Happened again
[05:30] <duflu> Umm, the mir 0.16.0 tarball is 50MB
[05:30] <duflu> wtf?
[05:31] <duflu> Ooh. Cemil included the .bzr repo :)
[05:34] <RAOF> Hehd.
[06:10] <RAOF> We should probably work out why linking with ld.gold fails.
[06:10] <RAOF> gold is much, *much* faster to link.
[06:11] <RAOF> (Like roughly an order of magnitude)
[06:11] <duflu> RAOF: What is gold?
[06:11] <RAOF> The gold linker. It's the replacement...ish for the standard bfd linkerl.
[06:11] <duflu> Oh  https://en.wikipedia.org/wiki/Gold_(linker)
[06:14] <RAOF> I think we might be technically underlinking.
[06:16] <RAOF> Also have multiple wildcards in the symbols.map, which gold dislikes (and *might* be UB)
[06:19] <duflu> Well, avoiding the wildcards would at least make us think about ABIs more :)
[06:19] <duflu> Hopefully it would be semi-automated tho
[06:20] <RAOF> No, I mean we have MIR_CLIENT_9 { global: stuff... local: * } MIR_CLIENT_9.1 { global: stuff... local: *};
[06:20] <duflu> Oh
[06:20] <RAOF> The two wildcards overlap, so it's not defined which block matches.
[06:21]  * duflu thinks he's not the only one who never bothered to learn about local:*
[06:21] <RAOF> It's a poor-man's -fvisibility=hidden :)
[06:22] <RAOF> Hm. We should totally use that for mirclient.
[07:40] <anpok> i guess only the last one should have local:*?
[07:44] <anpok> or only the first?
[09:27] <anpok> alan_g, alf_: https://code.launchpad.net/~andreas-pokorny/mir/libinput-platform-pointer-settings/+merge/272501/comments/687606 thoughts?
[09:28] <alan_g> anpok: on my list
[09:28] <anpok> the actual answer spans over to comments.. one that was started by a sleepy-me..
[09:28] <anpok> *two
[13:35] <tsdgeos> guys, did i do this right?
[13:35] <tsdgeos> https://code.launchpad.net/~aacid/mir/fix_forward_declarations/+merge/272751
[13:36] <tsdgeos> proper target branch and stuff?
[14:07] <alf_> Saviq: Do MPs for unity8 need an explicit changelog change or is the change automatically picked up from the commit messages?
[14:08] <Saviq> alf_, no changelog, just the commit message on the merge proposal
[14:08] <alf_> Saviq: thanks
[14:09] <tjaalton> hi, should unity8 desktop session work in current wily, or did my mesa11 break it?-)
[14:10] <alan_g> greyback_: CI now happy with https://code.launchpad.net/~alan-griffiths/qtmir/small-refactoring-of-MirWindowManager/+merge/266698
[14:21] <alan_g> tjaalton: I'm not sure what the state of u8 desktop is, but AFAIK the mesa 11 drop just broke Mir compilation, not runtime.
[14:25] <guest42315> tjaalton, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1499425
[14:25] <ubot5`> Ubuntu bug 1499425 in xorg-server (Ubuntu) "xmir black window (mesa 11.0.0)" [High,New]
[14:32] <anpok> tjaalton: hm a lot has changed inXmir .. I believe the wily version requires the -damage to workaround lots of redarw issues
[14:32] <anpok> *parameter
[14:33] <anpok> oh ok duflu already answered that..
[14:34] <anpok> s/tjaalton/guest42315
[14:35] <guest42315> que dice? oh yeah :D -damage doesn't work
[14:38]  * guest42315 ubuntuonair in 20 min http://ubuntuonair.com/
[14:42] <tjaalton> ah just compilation, no biggie then :)
[14:42] <tjaalton> so if the blank screen on login is due to the xmir bug then I guess it's known
[14:46] <tjaalton> and I did notice that one already, but thought it would be more native than using xmir
[14:47] <anpok> tjaalton: there is a high probability that those are not related
[14:48] <tjaalton> ok
[14:50] <tjaalton> could be I'm hitting a skylake display bug