[09:39] <duflu> alan_g, how do I stop fatal exceptions from reporting themselves and get a stack trace?
[09:40] <duflu> Oh, maybe I don't need to. Can guess what's crashing
[09:40] <alan_g> IIRC mir::fatal_error = mir::fatal_error_abort
[09:42] <duflu> alan_g: I mean on the command line :)
[09:43] <duflu> It's an exception, not a fatal error. But Mir is trying to do its own error report (!)
[09:44] <alan_g> I thought abort was the default
[10:22] <alan_g> mapreri: re bug 1675138 - the 0.26.2 release is in silo 2600 awaiting QA. I know camako has spent time getting it this far - do we need to set him back? Or can the packaging changes be made directly?
[10:57] <mapreri> alan_g: what do you mean by "directly"?
[10:57] <mapreri> (I didn't even remember I was on this channel!)
[10:59] <alan_g> Without resetting the process in bileto
[10:59] <mapreri> if you are fine with people uploading the package directly to the archive we can work it out, i.e. I upload a -2 as soon at 0.26.2-1 is uploaded, but then your next upload done through whatever CI should contain it.
[10:59] <alan_g> mapreri: that would work for me
[10:59] <mapreri> I have no idea how bileto (or whatever kind of CI/landing system) you are using work
[10:59] <mapreri> oh, great
[11:00] <mapreri> so, what would be the timing for 0.26.2 to land? :)
[11:01] <alan_g> mapreri: out of my hands, first QA need to approve and then someone needs to push to archive. But I'd guess the next day or two.
[11:01] <mapreri> that works just fine
[11:01] <mapreri> I'll arrange the -2 upload, will you please merge it in 0.26.3 in the meantime?
[11:03] <alan_g> AFAIK 0.26.3 doesn't exist (and likely won't). But I'll take care of it in that contingency.
[11:03] <mapreri> ack
[13:16] <greyback> anpok: hey, we're experiencing bug 1675357 where unity8 is getting continual key repeat events after you VT switch away. You were looking into key repeat bugs just like this, probably related?
[14:08] <anpok> greyback: yes ... mir fixes for that are in flight..
[14:08] <anpok> greyback: but there is already a fix in qtmir that should evade that problem: https://code.launchpad.net/~andreas-pokorny/qtmir/store-and-recover-cookie-and-input-device-id/+merge/318528
[14:09] <anpok> greyback: oh hold on.. thats a separate issue
[14:38] <camako> tjaalton, which branch of pkg-xorg/lib/vulkan.git do I use?
[14:38] <camako> debian-unstable?
[14:39] <camako> I don't see an 'ubuntu' branch
[14:39] <tjaalton> camako: because it's synced
[14:39] <camako> I need to make updates to make Mir useable in the loader
[14:39] <tjaalton> will you send them upstream?
[14:39] <camako> tjaalton, yes, but not right away
[14:40] <tjaalton> then just fork d-u
[14:40] <camako> tjaalton, so we don't distro-patch this, do we?
[14:40] <tjaalton> you will :)
[14:40] <camako> :-)
[14:40] <camako> thanks