[17:40] <mterry> Does anyone know why xvfbtestPreview in silo 2150 would segfault?  It's holding up our migration to release pocket in zesty
[17:41] <mterry> greyback, dandrader: ^ relevant to you
[17:41]  * dandrader looks
[17:42] <greyback> mterry: no idea. /me tries to repro locally
[17:42]  * mterry also tries locally
[17:42] <dandrader> mterry, any useful log?
[17:42] <mterry> No
[17:42] <mterry> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/u/unity8/20161213_162531_a0c3e@/log.gz
[17:42] <mterry> Search for "error 2"
[17:42] <mterry> Or xvfbtestPreview
[17:43] <mterry> It passes all tests
[17:43] <mterry> Then it segfaults
[17:43] <Saviq> not just that one, there's like a dozen segfaults
[17:43] <mterry> Both amd64 and i386 fail
[17:43] <Saviq> 10, actually
[17:43] <mterry> Right you are
[17:43] <Saviq> and yeah, both amd64 and i386, so not random
[17:44] <Saviq> something must've changed between silo and proposed, since we're green in automated
[17:44] <Saviq> I mean comparing these logs might be helpful https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2150-excuses/2016-12-07_23:50:01/2150_zesty_excuses.html
[17:45] <mterry> Saviq: wait aren't you on vacation?
[17:45] <Saviq> ish
[17:45] <mterry> get outta here
[17:45] <Saviq> promised to keep an eye out
[17:45] <mterry> ah
[17:45] <Saviq> anyway, it's in your hands so no need for me
[17:45] <mterry> :)
[18:18] <greyback> "Qt: Session management error: Could not open network socket" <- was this always printed on the console while running tests? (I get it locally, it's not printing on the server)
[18:18] <greyback> so far, tests are running ok locally
[18:18] <greyback> might be something in proposed breaking it
[18:27] <mterry> greyback: I don't recognize the error...  But yeah I bet proposed is the trigger
[18:28]  * mterry is still updating his zesty system, haven't used it for a bit since I've worked on u8 snap in xenial
[18:36] <greyback> QT_LOGGING_RULES=*=false needed for tests, as they're so noisy
[19:28] <mterry> ok I do get the segfault on proposed
[19:50] <greyback> mterry: what segvs? xvfb?
[19:50]  * greyback not had luck with his chroot
[19:54] <mterry> greyback: yeah it seems to only segfault with xvfb in the mix
[19:55] <mterry> But I'm not sure it's xvfb itself
[19:55] <mterry> I'm trying to isolate which package upgrade triggers it
[19:57] <mterry> stacktrace is in libgcc code, so something might need a rebuild against latest gcc
[20:18] <mterry> it's libmesa
[20:34] <greyback> oh man
[20:36] <mterry> rebuilding it to see if it just needs a rebuild against latest gcc and everything.  If that doesn't fix it, I'm out of my depth and Mirv seems out for the holidays
[20:36] <mterry> I suppose we could drop it from proposed in worst case
[23:12] <dmj_s76> Trevinho: I've had a chance to test the new unity hdpi scaling factor code on a wider range of hardware now, and think there are some cases where it doesn't do quite the right thing.
[23:14] <dmj_s76> It does do the right thing for 15" 1080P displays and 15" 4K displays, but forces non-integer scaling by default on 17" 4K displays and 14" 1080P displays.
[23:15] <dmj_s76> At least with existing toolkits, non-integer scaling tends to look somewhat wrong.