[00:40] <bschaefer> RAOF, o looks like cookie factory inst installing correctly?
[00:41] <RAOF> Hah! Indeed.
[00:41] <bschaefer> more protobuf issues for amd64
[00:41] <bschaefer> sad face until that gets fixes
[00:41] <bschaefer> fixed*
[00:41] <RAOF> We haven't added a libmircookie package to debian/control :)
[00:41] <bschaefer> RAOF, o duh, i added the nettle-dev to control
[00:42] <AlbertA> bschaefer: more? like what?
[00:42] <AlbertA> bschaefer: it's compiling and passing here with GCC (lp:mir)
[00:42] <bschaefer> AlbertA, more?
[00:42] <bschaefer> oo
[00:42] <bschaefer> AlbertA, umm in jenkins
[00:42] <bschaefer> lp:mir compiles fine for me locally
[00:42] <bschaefer> though its failing in clang
[00:43]  * bschaefer should try that
[00:44] <RAOF> Yeah, clang is known-broken with gcc-5 built stuff.
[00:44] <bschaefer> well at lease its not my fault haha
[00:45] <bschaefer> RAOF, so we need to create a cookie factory package?
[00:45] <bschaefer> ie library?
[00:45] <RAOF> Yup.
[00:45] <RAOF> libmircookie1
[00:45] <RAOF> + libmircookie-dev
[00:46]  * bschaefer attempts
[00:46]  * RAOF originally had this as an external project called libspoofless, but that was just soooooo much annoying overhead.
[00:46] <bschaefer> haha
[00:54] <bschaefer> RAOF, might need to be worded a bit better :)
[00:54] <bschaefer> http://paste.ubuntu.com/12121500/
[00:55] <RAOF> I can probably update the description in the branch if you like :)
[00:55] <bschaefer> RAOF, pushed if you want to change it
[00:55] <bschaefer> haha yeah
[00:55] <bschaefer> install files there
[05:16] <Mirv> RAOF: are you still about? can I get a core dev ack on Mir https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/lastSuccessfulBuild/artifact/mir_packaging_changes.diff ? (the debian/ files, the rest are just for information)
[05:16] <Mirv> seems ok changes and cleanups for me
[05:33] <RAOF> Mirv: Yeah, seems sensible to me.
[05:34] <Mirv> RAOF: thanks! I still need archive admin preNEW review though to ack the adding of binary packages, but 1/2 completed.
[05:56] <duflu> tvoss: Hey I found Jolla are to blame for our smoothness issues, kind of :)  https://bugs.launchpad.net/qtmir/+bug/1486341
[07:14] <RAOF> Oh, goody. That kernel panic corrupted my bzr working tree.
[07:55] <Mirv> duflu: it'd look to me that at least the MP linked to from QTBUG is only found in Qt 5.5 while the 5.4 branch has a crash fix that mentions it but apparently not the touch compression feature itself (looking at git logs at git://code.qt.io/qt/qtdeclarative.git)
[07:56] <duflu> Mirv: Yeah the QTBUG might not be related. But the introduction of the feature occurred in 5.4 AFAIK
[07:57] <Mirv> ok
[07:57] <duflu> I know because Gerry told me about it early last year
[07:57] <duflu> And it was about to be released then
[07:58] <Mirv> yeah I also think I remember some earlier discussions, it's probably an earlier feature that has been later refined
[07:59] <duflu> Mirv: Even if it worked properly, it would be redundant with what Mir already does
[08:03] <RAOF> Not quite; it can align event processing with Qt's renderloop, which Mir doesn't do.
[08:05] <duflu> RAOF: Nice in theory. In practice it's broken and everything works better without it :)
[08:17] <greyback> duflu: interesting findings on the touch scrolling, could it be the combination of the 2 input resampling engines being the problem, more than Qt's one alone?
[08:18] <duflu> greyback: Thought of that and apparently no. Turning off Mir's and just leaving Qt's the problem remains
[08:18] <greyback> duflu: ok
[08:18] <duflu> greyback: But please do try for yourself
[08:19] <greyback> will do
[08:19] <duflu> alf: OK, remind me who to ask to fix up the CI scripts?
[08:24] <duflu> greyback: Where in the architecture is it? Would apps have run though the compression twice or just once?
[08:28] <greyback> duflu: touch compression happens in each QQuickWindow. So the unty8 window will do compression before dispatching events to the qml scene.
[08:28] <duflu> greyback: I mean full stack. Just once then?
[08:28] <greyback> apps also have a QQuickWindow, and will use same compression logic
[08:28] <greyback> so no, multiple times
[08:28] <duflu> Hmm
[08:29] <duflu> That's great news. We might be able to go one better still
[09:00] <alf> duflu: it's usually fginther
[09:00] <alf> duflu: that fixes things for us
[09:00] <duflu> alf: OK, thanks
[09:01] <duflu> greyback: Is there a way to use desktop_file_hint without having a valid file?
[09:01] <greyback> duflu: having a valid file is the point :)
[09:02] <greyback> just point it to any existing file
[09:02] <duflu> greyback: Hmm, doesn't work. I might be using an incompatible Mir version or something
[09:02] <greyback> is unity8.log printing anything?
[09:03] <greyback> if client connection rejected, unity8 prints a REJECTED notice
[09:03] <greyback> just use something like /usr/share/applications/gedit.desktop
[09:03] <duflu> greyback: I get the app starting animation indefinitely
[09:04] <greyback> duflu: something else wrong so, that means the client has connected, but not drawn its first frame
[09:04] <duflu> greyback: Arg. We might have broken protocol compatibility
[09:04] <greyback> I think we've a bug where actually a couple of frames need to be drawn
[09:15] <duflu> alf: How do you feel about it landing (by hand) and then CI getting fixed?
[09:15] <duflu> It would have to be in that order
[09:16] <duflu> alf: Oh umm, or I could just hack the script to work
[09:16] <duflu> I might do that
[09:21] <alf> duflu: I wouldn't mind landing it first as long as CI gets fixed soon after (and CI is broken anyway so...)
[09:21] <duflu> alf: Never mind. I have a solution that won't need CI changes now
[09:23] <duflu> greyback: Confirmed, we broke protocol compatibility in lp:mir (clients don't talk to existing servers any more)
[09:23] <duflu> Need to bisect that
[09:23] <greyback> duflu: uh oh
[09:24] <greyback> recent?
[09:24] <duflu> greyback: Yeah, it was working at least a week or two ago
[09:38] <alf> duflu: seems like a good candidate for automated testing, something to consider for our new jenkins instance
[09:45] <duflu> alf: Kind of the reverse of what we have in glmark2. That tests the previous release client against the newer server (I think?)
[09:50] <alf> duflu: only if there is an ABI bump, otherwise glmark2 just uses the update library of the same ABI
[09:50] <duflu> How very predictable
[11:27] <kdub> alf, with lp:~afrantzis/mir/buffer-bind-to-render-image how does a mgm/mga::Buffer switch between gl binding and another sort of binding?
[11:30] <alf> kdub: In a future MP, we will have a Platform::create_buffer_allocator(RendererType const& renderer_type), so the buffer allocator will know to create buffers supporting the renderer
[11:32] <kdub> and, just guessing, will have something like: mgm/mga::Buffer::Buffer(..., std::shared_ptr<RenderTypeBinder> const&) ?
[11:36] <alf> kdub: Each platform can handle this as it sees fit internally, but what you propose is a reasonable approach if a platform supports multiple renderers. For the first step it's not needed since the existing platforms will just support "gles2".
[18:07] <kenvandine> kgunn, i don't know how to get debs of mir built that i can test on my device, how would you guys feel about adding my branch to silo 0 to so i can test it with my touchpad?
[18:07] <kenvandine> https://code.launchpad.net/~ken-vandine/mir/touchpad_pointer/+merge/268274
[18:07] <kenvandine> sound only affect touchpads, if it doesn't work we can reconfigure it again :)
[18:07] <kgunn> greyback_: ^ ?
[18:07] <kgunn> kenvandine: in general i don't mind
[18:08] <kgunn> i suppose we'd prefer to merge that into the silo0 branch for mir
[18:08] <kenvandine> sure, if it fixes it
[18:08] <kenvandine> but i haven't actually been able to test it :)