[00:57] <duflu> That's confusing...
[00:57] <duflu> mir (0.15.1+15.10.20150903-0ubuntu1) wily; urgency=medium
[00:57] <duflu>   [ Kevin Gunn ]
[00:57] <duflu>   * released-rebuild-for-vivid-overlay
[00:57] <duflu>  -- CI Train Bot <ci-train-bot@canonical.com>  Thu, 03 Sep 2015 18:50:01 +0000
[00:57] <duflu> but also doesn't change anything
[01:11] <robert_ancell> duflu, does XMir crash immediately when you launch it on a Nexus 4?
[01:11] <duflu> robert_ancell: Yeah, but I'm pretty sure I know why. I'll test and fix that today
[01:11] <robert_ancell> duflu, I'm wondering why I don't see that
[01:11] <duflu> No idea why your vivid would work cos it's the same package.
[01:12] <robert_ancell> perhaps you have newer drivers
[01:12] <duflu> robert_ancell: It might be you have an older kernel and your GLES version is < 3.0
[01:12] <duflu> That would make epoxy skip over the problem
[01:12] <robert_ancell> glamor GL version: OpenGL ES 3.0 V@53.0 AU@  (CL@) according to the log
[01:14] <robert_ancell> duflu, do you know how to get XMir to dump core on the phone? It seems ulimit -c unlimited doesn't help.
[01:14] <duflu> robert_ancell: It's a Xorg thing and I forget...
[01:14] <robert_ancell> And I love how that log message always says "dumping core" regardless of if if actaually does
[01:14] <duflu> robert_ancell: Yes it's dumping with a limit of zero
[01:14] <robert_ancell> I guess that's technically true
[01:15] <duflu> robert_ancell: The "dumping" message would come from libc or something, userspace. But the actual dumping is a kernel operation. So blame libc for not checking the kernel setting
[01:16] <robert_ancell> yeah, it's libc
[01:16] <robert_ancell> The -core flag is supposed to dump core but still not getting any core files
[01:17]  * duflu wishes nobody ever stripped debug symbols. Although that would require abandoning bloaty things like C++
[01:18]  * robert_ancell wishes we'd abandon C++
[01:19] <duflu> Well Microsoft kind of did. Apple completely did. Google mostly did. But you'll find small traces of C++ in all of them
[01:19] <duflu> -completely +mostly
[01:21] <RAOF> Even C is often much much bigger with debug symbols.
[01:34] <duflu> RAOF: Yes but much bigger C is still single digit bloat. C++ is often double or even triple digits (1-2 orders of magnitude)
[02:12] <duflu> robert_ancell: I'll confirm today but it might be uninitialized memory. So zero for me gives a nice crash. You however might have got some readable bytes, which would let it keep going since it's just doing strcmp
[02:13] <robert_ancell> zero what?
[02:13] <duflu> robert_ancell: Zero result from glGetStringi
[02:13] <duflu> NULL
[02:13] <robert_ancell> duflu, I'm getting your crash now, but only after updating to get your colour fixes
[02:14] <duflu> robert_ancell: Probably not related but also uninitialized memory issues would move with different logic. I'll confirm soon
[02:14] <duflu> I was getting the same crash before that fix
[02:14] <robert_ancell> yeah, I'm thinking something like that. The changes don't seem likely to cause the problem.
[02:14] <robert_ancell> ok
[02:59] <duflu> robert_ancell: This is annoying. epoxy is doing the right thing only calling GLESv3 functions after it confirms the version is >= 3.0. And hybris is doing the right thing, only claiming to export GLESv2 functions (which unfortunately for mako report their version as 3.0)
[02:59] <duflu> We need to break one of them
[03:00] <robert_ancell> duflu, how is mako reporting gles?
[03:00] <duflu> robert_ancell: The mako driver lives in /android and libhybris proxies into it with its own libGLESv2.so
[03:01] <robert_ancell> duflu, which part is saying it does 3.0?
[03:02] <duflu> robert_ancell: The log message on startup :)
[03:02] <duflu> From the GL version string
[03:02] <robert_ancell> duflu, why don't we make hybris export 3.0?
[03:02] <duflu> robert_ancell: Because it's structured to implement v1 and v2 separately. Adding v3 under that structure is a very large undertaking
[03:03] <robert_ancell> duflu, ok, but that sounds like the correct solution right? Instead of breaking one thing.
[03:05] <duflu> robert_ancell: It would be a silly investment of a large amount of time to implement all of v3. I'd rather stick the one v3 function we need in the v2 implementation. Or work around elsewhere
[03:05] <duflu> Our code actually links to GLESv2. It's just because epoxy queries things dynamically that we find it using v3 functions
[03:06] <duflu> Actually fixing epoxy to limit its efforts to GLESv2 might be more sane
[03:12] <duflu> Yes, I will do a one line mod to epoxy so it will never crash when used with hybris...
[03:21] <duflu> RAOF: If I want to add an Ubuntu-only patch to a package that is still "copied from debian sid", who do I talk to?
[03:22] <robert_ancell> duflu, you just need anyone with appropriate upload permissions
[03:22] <robert_ancell> duflu, do you want to patch libepoxy?
[03:23] <duflu> robert_ancell: Lemme check it works first ;)
[03:25] <duflu> robert_ancell: Success! It now fails later, the same as on desktop with -egl
[03:26] <duflu> Although I might need a second epoxy fix for that. Let's see
[03:33] <duflu> robert_ancell: Here tis. This might change what you see too:  https://bugs.launchpad.net/ubuntu/+source/libepoxy/+bug/1494240/comments/4
[03:33] <robert_ancell> duflu, ta
[04:25] <robert_ancell> duflu, it looks like GLES3 uses libGLES2.so so it's probably not hard to add a few new wrapped functions in hybris
[04:39] <duflu> robert_ancell: Not worth the effort. The epoxy fix is logically correct for any GL version. So is safe to keep
[04:39] <robert_ancell> duflu, excepts it's a patch that will never be accepted  upstream
[04:40] <duflu> robert_ancell: We could modify it to delete the unnecessary redundant (and crashing) code. That would also be correct
[04:40] <robert_ancell> duflu, which code is crashing?
[04:49] <duflu> robert_ancell: The strcmp after glGetStringi
[04:50] <duflu> robert_ancell: It's an Ubuntu-specific problem. I'm happy to make it an Ubuntu-only patch, or generalize a proposal to upstream under the title of "add support for libhybris" (which is not Ubuntu specific)
[04:50] <robert_ancell> duflu, but I don't get why we don't just make hybris wrap glGetStringi
[04:50] <duflu> Although I suspect more libepoxy fixes will be required first
[04:50] <robert_ancell> Then everything will just work right?
[04:51] <duflu> robert_ancell: Yes, but that's uglier and less correct. You're adding v3-only function to something that only claims to support v2
[04:51] <duflu> Using glGetString instead of glGetStringi works for all versions. Nice and cleanly
[04:52] <duflu> Also, I think we might need to make additional patches to libepoxy's extension maps, unrelated to this
[04:53] <duflu> So can't escape needing to patch libepoxy
[04:53] <duflu> A third reason is it would help Mir a lot. But Mir can't use it till we fix it
[05:17]  * robert_ancell -> EOD
[10:26] <Mirv> is greyback on holidays? I now got the total hang on my personal use krillin again and filed bug #1494692 (I'll fill in more later)
[10:29] <Mirv> (ok, yes he is)
[13:03] <kgunn> alf_: did pat's new log help any on that sms-freezes ui bug ?
[13:04] <alf_> kgunn: I am going to look into that in a bit, I wanted to first publish the voice call blanking improvements
[13:04] <alf_> kgunn: feel free to try out https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+packages
[13:04] <kgunn> sure
[13:05] <kgunn> alf_: pat has a special love for us...did you see he logged another
[13:05] <kgunn> https://bugs.launchpad.net/bugs/1494513