[00:29] <robert_ancell> Pharaoh_Atem, yes, that was what I was thinking :(
[00:51] <Pharaoh_Atem> robert_ancell: I have a rediffed version of the patch (http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/Mir/libinput.git/tree/libinput-1.5.0-touch-point-orientation.patch), but there's literally no way I can ever *hope* to consider getting Mir in Fedora proper while patches are required in libinput and mesa
[00:53] <Pharaoh_Atem> robert_ancell: though I suspect the Mesa people aren't particularly happy with the idea that Mir turns Mesa GPLv3
[00:53] <Pharaoh_Atem> which might explain why the platform support patch hasn't made it in
[00:54] <robert_ancell> Pharaoh_Atem, what's the GPLv3 issue?
[00:54] <Pharaoh_Atem> the community doesn't particularly care for copyleft licenses at all
[00:54] <Pharaoh_Atem> Wayland is licensed under the same terms as Mesa and Xorg (X11 Expat license)
[00:55] <Pharaoh_Atem> they're more in the "copyfree" (or as I call it, "pushover") camp
[00:56] <Pharaoh_Atem> robert_ancell: that particular community is made up of Linux, BSD, Windows, and various other platform people
[00:57] <Pharaoh_Atem> with the exception of Linux, all of them prefer permissive licensing
[00:57] <robert_ancell> Pharaoh_Atem, but how is Mir affecting the Mesa license?
[00:57] <Pharaoh_Atem> in order for Mir to function, Mesa must have a platform module built into it
[00:57] <Pharaoh_Atem> which links the Mir libraries
[00:58] <Pharaoh_Atem> thus, Mesa, when compiled with Mir support, goes from X11/MIT to GPLv3
[01:00] <robert_ancell> Pharaoh_Atem, the Mir client library is LGPL, so that shouldn't be an issue
[01:00] <RAOF> No; it goes to LGPLv3
[01:01] <RAOF> Or, rather, it remains X11/MIT as long as you don't statically link libmirclient in.
[01:01] <Pharaoh_Atem> ah, so the mesa client libs are LGPLv3 then?
[01:01] <RAOF> libmirclient is LGPLv3.
[01:02] <RAOF> Anything you need for writing clients (or drivers) is LGPL; if you want to write a server, those libraries are GPL.
[01:03] <Pharaoh_Atem> hmm
[01:03] <RAOF> The reason why the platform support patch hasn't made it in is that we need to blow it up in the immediate future.
[01:03] <Pharaoh_Atem> blow it up?
[01:03] <RAOF> Change the API.
[01:04] <RAOF> Change the types you hand to EGL.
[01:04] <Pharaoh_Atem> is that happening soon?
[01:04] <RAOF> Yes.
[01:05] <RAOF> The Mir plumbing required to do that has either landed or is in a reveiewable MP, I think.
[01:06] <RAOF> The final step is to publish that API and migrate the platform patch.
[01:06] <RAOF> (And, obviously, to migrate all the downstreams. Yay!)
[01:07] <Pharaoh_Atem> well, the downstreams aren't exactly plentiful, so that's not nearly as big of an issue
[01:07] <RAOF> Right. *Particularly* when the patch isn't upstream.
[01:07]  * RAOF is also somewhat glad he never quite got around to implementing EGL_KHR_platform_mir support, so we can update that spec before it's released.
[01:09] <RAOF> Incidentally, thanks for doing the Fedora packaging work.
[01:10] <Pharaoh_Atem> unfortunately, it's all broken
[01:10] <Pharaoh_Atem> Mesa in Fedora is now at v13
[01:10] <Pharaoh_Atem> and that patch is not trivial to rebase
[01:10] <Pharaoh_Atem> RAOF: it seems like *technically* it's possible to use Mir without the mesa patch
[01:11] <Pharaoh_Atem> so the *bare minimum* for me being willing to put Mir through review in Fedora would be to get the libinput patch upstreamed
[01:11] <Pharaoh_Atem> as it won't compile without it
[01:11] <RAOF> It is. You can't run GL clients, but you can run GL shells and software-rendered clients.
[01:11] <Pharaoh_Atem> eugh
[01:12] <Pharaoh_Atem> not a great experience then
[01:12] <RAOF> Yes.
[01:12] <RAOF> EGL unavoidaby requires platform-integration for different display servers.
[01:13] <RAOF> (At least until someone proposes and implements a vendor-neutralish EGL with platform integration bits, like Android).
[01:13] <Pharaoh_Atem> well, that would require the big Linux companies and the big GL consumers to come together to agree on something
[01:14] <Pharaoh_Atem> we can't have that! </sarcasm>
[01:15] <RAOF> Heh. glvnd now exists, vulkan has a mostly-sensible ICD system.
[01:15] <RAOF> Things are getting better :)
[01:15] <Pharaoh_Atem> glvnd *barely* made it into Fedora 25
[01:15] <Pharaoh_Atem> so we have that fully enabled
[01:16] <Pharaoh_Atem> well, technically, it made it to Fedora 23+
[01:16] <Pharaoh_Atem> but we're starting to use it with Fedora 25
[01:16] <RAOF> And in another 10 years or so maybe we can remove the previous Linux OpenGL ABI!
[01:16] <Pharaoh_Atem> yeah, no
[01:16] <Pharaoh_Atem> you're asking for way too much
[01:17] <Pharaoh_Atem> even Apple and Microsoft haven't done that
[01:18] <RAOF> Yeah, I know it's not going to happen.
[01:19] <Pharaoh_Atem> my main interest in Mir has been to see if I can accomplish what many of my predecessors say is impossible: get Unity working properly on Fedora, without downgrading half the world
[01:19] <Pharaoh_Atem> and since Unity 7 is on life support, I've looked toward Unity 8
[01:20] <RAOF> Unity8 should be helpful there, as it mostly doesn't rely on GNOME patches.
[01:20] <RAOF> (And Qt is friendlier to downstream platform integration)
[01:21] <Pharaoh_Atem> yes
[01:22] <Pharaoh_Atem> it helps that since I'm more of a KDE guy myself, I'm more familiar with that stack
[01:22] <RAOF> Although I also think that much of our Qt stuff is upstream.
[01:23] <RAOF> Although not qtmir, because it's a fast moving target.
[01:23] <Pharaoh_Atem> it is, but it's disabled in Fedora since we don't have the scaffolding for it
[01:23] <Pharaoh_Atem> i.e. Mir itself
[01:23] <Pharaoh_Atem> and various unity libraries
[01:23] <RAOF> Heh
[01:23] <Pharaoh_Atem> well, we recently brought back libunity and libappindicator, since Plasma 5 now uses them
[01:24] <Pharaoh_Atem> I've never been happy with how those projects are managed, though
[01:24] <Pharaoh_Atem> we're forced to yank tarballs from the ubuntu archive because the lp projects are dead wastelands with no updated releases ever made
[01:25] <RAOF> Embrace the rolling release + CI pipeline!
[01:25] <RAOF> It Is Life
[01:26] <Pharaoh_Atem> well, that would require things like mir's gmock tests to actually work
[01:27] <RAOF> (Or, more seriously, is hostile to downstreams)
[01:27] <Pharaoh_Atem> right
[01:27] <Pharaoh_Atem> I've always had a bit of lethargy for working with Launchpad-hosted projects, because they tend to do this to me
[01:28] <Pharaoh_Atem> irony of ironies, my very first package in Fedora is of a piece of software hosted on Launchpad
[01:28] <RAOF> There was a time when our projects would do actual releases, but not now. Mir is an outlier in that we *do* do releases.
[01:28] <RAOF> (Because we don't have a stable C++ ABI, so updating Mir requires rebuilding the world, so we don't do that every commit ☺)
[01:29] <RAOF> On the plus side, you *should* be able to take a random trunk commit and have it work properly.
[01:29] <Pharaoh_Atem> nope
[01:29] <Pharaoh_Atem> I won't trust that until I can run gmock tests
[01:30] <RAOF> What's broken there? We don't patch googletest.
[01:30] <Pharaoh_Atem> unfortunately, for some reason I cannot fathom, Mir's CMake script can't detect gmock and gtest
[01:30] <RAOF> Does fedora just lack the latest gtest?
[01:30] <RAOF> Huh. Maybe you install it in an odd place?
[01:30] <Pharaoh_Atem> https://apps.fedoraproject.org/packages/gtest
[01:31] <Pharaoh_Atem> https://apps.fedoraproject.org/packages/gmock
[01:31] <RAOF> Alternatively, maybe you don't install the sources and expect projects to link to prebuilt libraries?
[01:31] <Pharaoh_Atem> for gmock, it's sources
[01:31] <Pharaoh_Atem> for gtest, it's libraries
[01:31] <Pharaoh_Atem> https://apps.fedoraproject.org/packages/gmock/sources/spec/
[01:32] <Pharaoh_Atem> https://apps.fedoraproject.org/packages/gtest/sources/spec/
[01:32] <RAOF> Well, we have googletest 1.8.0 in zesty. But we don't require it.
[01:32] <RAOF> Right. Our gtest detection won't work unless you've got the gtest sources unpacked somewhere.
[01:32] <RAOF> (As is recommended by upstream)
[01:32] <Pharaoh_Atem> upstream dropped that recommendation when they fully moved over to cmake
[01:33] <Pharaoh_Atem> the apt guys told me the same thing...
[01:34]  * RAOF heads out.
[01:36] <Pharaoh_Atem> RAOF: https://github.com/Debian/apt/commit/99ba7cc1901c761c97d67775f23858b86594f2ba
[09:03] <anpok_> Pharaoh_Atem: it was proposed but not yet added because a way to calibrate/scale the reported touch contact size unit into something meaningful was missing..