[02:19] soreau, i find it ironic that people seem to be using the same arguments against northfield/norwood that you used against mir -- it's unnecessary, it's divisive, they're personally offended etc. [02:20] and you are using some of the same arguments that canonical used to defend mir -- weston doesn't do what i want, they don't want to work with me etc. [02:22] Canonical seems to have a pattern though of not playing well with others. [02:22] The one time I know of they actually got something going with an external upstream on design, they retroactively applied the CLA to it and threw away all the externally developed code. [02:23] ScottK, i'm not going to argue the "not invented here" thing [02:24] but if you read the irc exchange after mir was announced soreau was one of hte loudest anti-mir voices, saying he was personally offended by the decision [02:25] AFAICT, that was a pretty universal reaction though among people that don't work for Canonical. [02:25] meh [02:26] wayland's been around since the shrub administration and it still can't minimize windows... [02:26] After proclaiming it the next thing, how much effort did Canonical invest in helping develop it? [02:27] There may be valid technical arguments to go your own way, but I don't think Wayland wasn't making progress fast enough is one of them. [02:27] was it canonical's sole responsibility? [02:28] No, but Canonical is investing far more effort into Mir than they did into Wayland, so they could have, at least in terms of resource allocation, made different choices. [02:31] i really wonder who was hard to work with at this point, canonical or wayland's core devs [02:34] I don't know. It does seem that there is a pattern though of Canonical development efforts with other groups not resulting in successful cooperation. [02:34] phone. phone is what's important in the short term. [02:35] They could have had a phone two years ago, but they didn't care, so now it's a crisis. [02:35] ScottK, the NIH issue is beyond dispute at this point, i get that [02:36] It's a real problem for those of us interested in more than Ubuntu/Canonical OEM commitments. [02:38] Sarvatt, mir is better for phones than wayland? i don't understand the tech behind it [02:38] its too late here to get into it but it wont affect anyone !ubuntu, why is that a problem.. [02:39] because of the lingering NIH issue i guess [02:40] because lightdm wont grow a wayland session manager that can be used for free? [02:40] why not? [02:42] Personally, I care about Kwin upstream considering it an unsupported platform. Even if your X support is flawless, pretty much any Kubuntu related Kwin bug I expect to get marked invalide. [02:45] i'm sure kubuntu will become less and less stable in the future [02:49] I've no idea if it will or not. [02:56] ScottK: If kwin blanket rejects kubuntu-related bugs then they'll just be being hostile. There won't be a technical reason for it. [02:56] RAOF: I think "you're running on a platform I don't understand" is valid. [02:57] But it *won't* be running on a platform they don't understand. [02:57] It'll be running on X. [02:57] Only in the short term. [02:57] No, in the long term. [02:58] Then it's X on Mir. [02:58] Right. [02:58] why couldn't kwin be adapted to run natively on mir [02:58] And rejecting bugs for X on Mir makes as much sense as rejecting bugs for using radeon's UMS code. [02:59] bjsnider: Because upstream isn't interested in supporting upstream patches for single distro requirements. [02:59] RAOF: Maybe they won't. I don't know. [02:59] who knows if it will be just single-distro [03:00] So far the track record of Canonical stuff being single distro is pretty consistent. [03:00] If it's not, it's not, but I'm not holding my breath. [03:01] bjsnider: ‘kwin natively on Mir’ isn't really a well-formed statement. Mir isn't a generic display server in the same way Xorg is. [03:01] Heh, upstart got pretty widely adopted. :) [03:01] i admit i'm not well-versed in the tech [03:02] RAOF: Yes. Upstart best exception to the rule. [03:02] RAOF: What would be the well formed statement then? [03:03] Personally, I think the reason systemd appeared and replaced upstart in Fedora was someone noticed it was interfering with their "Canonical doesn't contribute" meme. [03:04] ScottK: That, and because Lennart apparently really wanted to write libOS [03:04] So I don't think everything is Canonical's fault, but there are common threads. [03:05] Lightdm would have likely been the official KDE upstream replacement for KDM is not for the CLA requirement. [03:07] Yeah. I don't think Mark's goal with the Canonical-should-use-CLA is a bad one, but I think it's been a good excuse for others not to accept our contributions. [03:07] I don't think it's an excuse at all. [03:08] I think that for some it is. [03:08] I think free software developers are rationale hostile to the idea that a third party should have the right to use their code in proprietary applications. [03:08] ScottK: ‘kwin as a display-server using Mir’ would probably be well-formed, as would ‘A Mir backend for kwin's Wayland compositor’. [03:08] No doubt. [03:08] rationale/rationally [03:09] It's a particularly sensitive subject for KDE as Canonical took code that KDE developers had contributed to appmenu-qt and then tossed it out after Canonical retroactively required copyright assignment. [03:15] That's not wonderful :/ [03:16] did they end up replacing kdm anyway? [03:26] They are working on it. [03:26] It's not going to make it into the Qt5/QML world. [03:27] lightdm would have been the clear choice except for the CLA. [03:28] so did they have to reinvent the wheel? [03:31] Pretty much. Let me find the blog post. [03:32] http://aseigo.blogspot.com/2013/03/logging-into-plasma-workspaces-2.html [03:33] The reaction to that seemed to pretty much be, "Where do I get the sddm code, we better get to work". [03:52] * RAOF really doesn't understand calling the CLA ‘non-free’; the only danger is that Canonical might choose at some future point to not make further improvements available under the GPL. At which point you just fork the project at the revision before the license change. [03:54] No, Canonical also gets the rights to distribute the code under a dual license proprietary/free approach if they want. [03:55] Which is a strictly *less bad* situation, right? [03:56] No. [03:57] Why should Canonical get rights no one else has if we're doing collaborative free software development? [03:57] The given answer is "we're doing most of the work", but that's a tautology. [03:58] If you arrange things so that others are reluctant to contribute (and if they should be or not, it's clear they are) then you'll always be doing most of the work. [03:58] Partially, but even if we were as welcoming as possible it's highly likely that Canonical would be doing most of the work. [03:59] It depends on the project. [04:00] Probably, yes. [04:03] Even so, I don't think "we're doing most of the work" is a good reason. [04:03] IMO, we're either doing free software development or we aren't. [04:03] If we are, Canonical doesn't need the proprietary rights. If we aren't, they should pay me for what I do. [04:25] I'd argue you are getting paid, just in code and infrastructure. If I submit a patch to mariadb, I get paid in a solid SQL database. [04:46] morning === tomreyn_ is now known as tomreyn === dj_ryan_ is now known as dj_ryan === MonsterKiller_ is now known as MonsterKiller [10:39] argh, forgot to account for the possibility that preinit was simply called twice, grr! [10:40] no wonder I had a leak.. [10:42] hey, could somebody review/consider the patch on https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1079096 for raring? ;-) [10:42] Launchpad bug 1079096 in xorg-server (Ubuntu) "Xephyr does not have GLX" [Low,In progress] [10:42] oh sure [10:43] mlankhorst, thanks [10:43] but I'm debugging some other issue first :P [10:43] yeah, no hurry [12:35] oh god.. xorg is a mess [12:51] hm I guess the most sane solution is to disable xv and xvmc if creating a gpu screen === fenris is now known as Guest97540 === jono is now known as Guest461 === JanC_ is now known as JanC === seb128_ is now known as seb128 === seb128_ is now known as seb128