[gentoo-dev] RFC: using Ninja in more CMake-based packages

[gentoo-dev] RFC: using Ninja in more CMake-based packages

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

Hello, developers.

As you probably know already, CMake sucks a lot. One of its more sucky
features is that it generates Makefiles that fail a lot. In particular,
they fail at verbose build logs that are cluttered with useless CMake
intermediate commands and hard to read. But also they sometimes
deadloop hard in faulty dependency scanning [1].

Those two issues can be solved by switching CMake to use Ninja instead
of make. As you may know, Ninja is the fancy building tool that is
faster and much harder to use than make. However, it integrates with
CMake much better and with less hackery. In particular, the verbose
build log is free of useless CMake percentage printing output and other
non-sense, and contains only real build commands. It also gets
dependency scanning right.

Sadly, there are two problems with using Ninja:

1) it will not work with some packages,

2) it introduces an extra dep (on Ninja).

The first issue is a bit complex. Sometimes the problem lies in CMake
itself (not all CMake magic works in Ninja for some reason), sometimes
in the project (relying on Makefile stuff), sometimes in the ebuild.
For example, with Ninja you can't do '-C subdirectory' to run targets
from a specific subdirectory. So, we can't force Ninja everywhere.

The second issue is a bit easier. GNU make is part of @system, ninja
would be considered an extra package being installed. Do we consider it
fine to require it randomly? Or do we need to justify the extra dep by
benefits of building a particular package with Ninja? Is sane verbose
build log a good enough benefit?

So, what do you think? Should I start switching random packages to
Ninja whenever it works?

Oh, and this would be done via something like:

  : ${CMAKE_MAKEFILE_GENERATOR:=Ninja}

before inherit line. To respect user forcing another generator, and to
get deps right.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=546336

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Johannes Huber]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
> Hello, developers.

Hello Michal,

> As you probably know already, CMake sucks a lot. One of its more sucky
> features is that it generates Makefiles that fail a lot. In particular,
> they fail at verbose build logs that are cluttered with useless CMake
> intermediate commands and hard to read. But also they sometimes
> deadloop hard in faulty dependency scanning [1].
>
> Those two issues can be solved by switching CMake to use Ninja instead
> of make. As you may know, Ninja is the fancy building tool that is
> faster and much harder to use than make. However, it integrates with
> CMake much better and with less hackery. In particular, the verbose
> build log is free of useless CMake percentage printing output and other
> non-sense, and contains only real build commands. It also gets
> dependency scanning right.
> 
> Sadly, there are two problems with using Ninja:
> 
> 1) it will not work with some packages,
> 
> 2) it introduces an extra dep (on Ninja).
> 
> The first issue is a bit complex. Sometimes the problem lies in CMake
> itself (not all CMake magic works in Ninja for some reason), sometimes
> in the project (relying on Makefile stuff), sometimes in the ebuild.
> For example, with Ninja you can't do '-C subdirectory' to run targets
> from a specific subdirectory. So, we can't force Ninja everywhere.
> 
> The second issue is a bit easier. GNU make is part of @system, ninja
> would be considered an extra package being installed. Do we consider it
> fine to require it randomly? Or do we need to justify the extra dep by
> benefits of building a particular package with Ninja? Is sane verbose
> build log a good enough benefit?
> 
> So, what do you think? Should I start switching random packages to
> Ninja whenever it works?
> 
> Oh, and this would be done via something like:
>   : ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
> 
> before inherit line. To respect user forcing another generator, and to
> get deps right.
> 
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336

KDE herd maintains ~1000 packages and the majority relies on CMake. I am not 
aware of any reports about GNU make related build files. So i would vote for 
the reliable GNU make generator.

Greetings,

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Justin Lecher (jlec)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/06/15 22:14, Johannes Huber wrote:
> Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
>> Hello, developers.
> 
> Hello Michal,
> 
>> As you probably know already, CMake sucks a lot. One of its more
>> sucky features is that it generates Makefiles that fail a lot. In
>> particular, they fail at verbose build logs that are cluttered
>> with useless CMake intermediate commands and hard to read. But
>> also they sometimes deadloop hard in faulty dependency scanning
>> [1].
>> 
>> Those two issues can be solved by switching CMake to use Ninja
>> instead of make. As you may know, Ninja is the fancy building
>> tool that is faster and much harder to use than make. However, it
>> integrates with CMake much better and with less hackery. In
>> particular, the verbose build log is free of useless CMake
>> percentage printing output and other non-sense, and contains only
>> real build commands. It also gets dependency scanning right.
>> 
>> Sadly, there are two problems with using Ninja:
>> 
>> 1) it will not work with some packages,
>> 
>> 2) it introduces an extra dep (on Ninja).
>> 
>> The first issue is a bit complex. Sometimes the problem lies in
>> CMake itself (not all CMake magic works in Ninja for some
>> reason), sometimes in the project (relying on Makefile stuff),
>> sometimes in the ebuild. For example, with Ninja you can't do '-C
>> subdirectory' to run targets from a specific subdirectory. So, we
>> can't force Ninja everywhere.
>> 
>> The second issue is a bit easier. GNU make is part of @system,
>> ninja would be considered an extra package being installed. Do we
>> consider it fine to require it randomly? Or do we need to justify
>> the extra dep by benefits of building a particular package with
>> Ninja? Is sane verbose build log a good enough benefit?
>> 
>> So, what do you think? Should I start switching random packages
>> to Ninja whenever it works?
>> 
>> Oh, and this would be done via something like: :
>> ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
>> 
>> before inherit line. To respect user forcing another generator,
>> and to get deps right.
>> 
>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
> 
> KDE herd maintains ~1000 packages and the majority relies on CMake.
> I am not aware of any reports about GNU make related build files.
> So i would vote for the reliable GNU make generator.
> 

I tested ninja some while ago on some big cmake science projects and I
found it to be faster. So I would vote for Micheals suggestion. Though
I also never faced any problems with the makefiles either. It's purely
that I found ninja to work smooth and fast.

Justin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVdKc1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiDBQP/R2vvdQGBOUGHX5wNHCjJxoy
XPQdJq7Y+ihrDj+630/EIzvncZjLXpJ1r03ftfQ8Km38m1dIL9HHVIX4Z6NHokwe
bmEs1VAQk+3NajmzB4Wt6xJoiIPiQiIDeNLAYhe8MVL1qK+LW5sgC8gV7PWwau7b
7CsBbPJOE1Y/rcjc8B3c630hE8WXAfQ1lnIBR7EzNsnNwTp5s8F4u7JktZSKkSSc
g1545i8EBaV2eHeEatIqEpB2oGDp2eDZjeLny7nlCU0FO0MfFFsTWBXEJHUDIto4
ammwydyWLGBACU97jBkoePgSp54ekAW3XdtMFG9KT7/rArtgDY06wWFH2BqA0tcx
qYGXqT1QBzjjUmTyQmHflKv3Zx233RD2h4J2g9A0wE5CKZViKdfKWADG0tyIRlOI
ooZKj7sp/iKZbgQqVdHPqySw7clUFi0LGUr7RQr/RUC1z+ROSb+x+dCkSV9ujPSF
A8acKoEu7cjjGU4P/RFiWbHR/czMXiv21VmAvD4sdqibkYlfR/YWyctz0JMzfIdz
tB6ZDpedB3Qsu0tTdlnOYiCMpoMH/ZBK3vjLcG/72BkqjyyD32xJu1KVVARao+ZQ
4cOxNXDA35yeOnZ77pNLNhkS8CToGuijqtUdkDhYq+rhLFOkNcTbl+fR88UuTeAH
ZwGZmZGkP1jubaDIN+NL
=17Cu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Christoph Junghans]

2015-06-07 14:19 GMT-06:00 Justin Lecher (jlec) <jlec@gentoo.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 07/06/15 22:14, Johannes Huber wrote:
>> Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
>>> Hello, developers.
>>
>> Hello Michal,
>>
>>> As you probably know already, CMake sucks a lot. One of its more
>>> sucky features is that it generates Makefiles that fail a lot. In
>>> particular, they fail at verbose build logs that are cluttered
>>> with useless CMake intermediate commands and hard to read. But
>>> also they sometimes deadloop hard in faulty dependency scanning
>>> [1].
>>>
>>> Those two issues can be solved by switching CMake to use Ninja
>>> instead of make. As you may know, Ninja is the fancy building
>>> tool that is faster and much harder to use than make. However, it
>>> integrates with CMake much better and with less hackery. In
>>> particular, the verbose build log is free of useless CMake
>>> percentage printing output and other non-sense, and contains only
>>> real build commands. It also gets dependency scanning right.
>>>
>>> Sadly, there are two problems with using Ninja:
>>>
>>> 1) it will not work with some packages,
>>>
>>> 2) it introduces an extra dep (on Ninja).
>>>
>>> The first issue is a bit complex. Sometimes the problem lies in
>>> CMake itself (not all CMake magic works in Ninja for some
>>> reason), sometimes in the project (relying on Makefile stuff),
>>> sometimes in the ebuild. For example, with Ninja you can't do '-C
>>> subdirectory' to run targets from a specific subdirectory. So, we
>>> can't force Ninja everywhere.
ninja has a "-C" option, too, but cmake only generates one build.ninja
in the root directory instead of a Makefile in every directory which
has a CMakeLists.txt.

>>>
>>> The second issue is a bit easier. GNU make is part of @system,
>>> ninja would be considered an extra package being installed. Do we
>>> consider it fine to require it randomly? Or do we need to justify
>>> the extra dep by benefits of building a particular package with
>>> Ninja? Is sane verbose build log a good enough benefit?
>>>
>>> So, what do you think? Should I start switching random packages
>>> to Ninja whenever it works?
>>>
>>> Oh, and this would be done via something like: :
>>> ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
>>>
>>> before inherit line. To respect user forcing another generator,
>>> and to get deps right.
>>>
>>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
>>
>> KDE herd maintains ~1000 packages and the majority relies on CMake.
>> I am not aware of any reports about GNU make related build files.
>> So i would vote for the reliable GNU make generator.
>>
>
> I tested ninja some while ago on some big cmake science projects and I
> found it to be faster. So I would vote for Micheals suggestion. Though
> I also never faced any problems with the makefiles either. It's purely
> that I found ninja to work smooth and fast.
Right after this feature was implemented (bug #430608), ago did some
testing on kde-base/kdelibs, but only found a 40 sec save on a 6min
overall build.

Christoph
>
> Justin
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0
>
> iQJ8BAEBCgBmBQJVdKc1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
> OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiDBQP/R2vvdQGBOUGHX5wNHCjJxoy
> XPQdJq7Y+ihrDj+630/EIzvncZjLXpJ1r03ftfQ8Km38m1dIL9HHVIX4Z6NHokwe
> bmEs1VAQk+3NajmzB4Wt6xJoiIPiQiIDeNLAYhe8MVL1qK+LW5sgC8gV7PWwau7b
> 7CsBbPJOE1Y/rcjc8B3c630hE8WXAfQ1lnIBR7EzNsnNwTp5s8F4u7JktZSKkSSc
> g1545i8EBaV2eHeEatIqEpB2oGDp2eDZjeLny7nlCU0FO0MfFFsTWBXEJHUDIto4
> ammwydyWLGBACU97jBkoePgSp54ekAW3XdtMFG9KT7/rArtgDY06wWFH2BqA0tcx
> qYGXqT1QBzjjUmTyQmHflKv3Zx233RD2h4J2g9A0wE5CKZViKdfKWADG0tyIRlOI
> ooZKj7sp/iKZbgQqVdHPqySw7clUFi0LGUr7RQr/RUC1z+ROSb+x+dCkSV9ujPSF
> A8acKoEu7cjjGU4P/RFiWbHR/czMXiv21VmAvD4sdqibkYlfR/YWyctz0JMzfIdz
> tB6ZDpedB3Qsu0tTdlnOYiCMpoMH/ZBK3vjLcG/72BkqjyyD32xJu1KVVARao+ZQ
> 4cOxNXDA35yeOnZ77pNLNhkS8CToGuijqtUdkDhYq+rhLFOkNcTbl+fR88UuTeAH
> ZwGZmZGkP1jubaDIN+NL
> =17Cu
> -----END PGP SIGNATURE-----
>



-- 
Christoph Junghans
http://dev.gentoo.org/~ottxor/

[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Duncan]

Christoph Junghans posted on Sun, 07 Jun 2015 20:08:25 -0600 as excerpted:

> 2015-06-07 14:19 GMT-06:00 Justin Lecher (jlec) <jlec@gentoo.org>:
>>
>> On 07/06/15 22:14, Johannes Huber wrote:
>> 
>>> Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
>>>
>>>> CMake sucks a lot [but will suck less if we switch] CMake to use
>>>> Ninja instead of make. As you may know, Ninja is the fancy building
>>>> tool that is faster and much harder to use than make. However, it
>>>> integrates with CMake much better and with less hackery.
 
>>>> GNU make is part of @system, ninja would be considered an extra
>>>> package being installed. Do we consider it fine to require it
>>>> randomly?

>>> KDE herd maintains ~1000 packages and the majority relies on CMake.
>>> I am not aware of any reports about GNU make related build files. So i
>>> would vote for the reliable GNU make generator.
>>>
>> I tested ninja some while ago on some big cmake science projects and I
>> found it to be faster. So I would vote for Micheals suggestion. Though
>> I also never faced any problems with the makefiles either. It's purely
>> that I found ninja to work smooth and fast.

> Right after this feature was implemented (bug #430608), ago did some
> testing on kde-base/kdelibs, but only found a 40 sec save on a 6min
> overall build.

That's still 10-11% (depending on what side of 6 minutes the 40 seconds 
goes), a pretty sizable difference considering it's just the maker we're 
fiddling with, not the compiler.

[TL;DR summary: yes to marking packages and automating ninja where safe 
for users that want to, but please keep gnu make the default.]

And on those ~1000 kde packages, for live users with ccache cutting 
compile time and thus speeding overall builds, the figure is likely to be 
MUCH higher than 10%.  WAG of 50%?  Anyone?

That said, I'm conservative enough to lean toward gnu make as well, 
certainly by default.  But were there a standardized ebuild flag to mark 
it ninja compatible, and a documented way to change that default, I'd 
also almost certainly try ninja, particularly when I /am/ doing live-kde 
as I was for a couple years with kde4, and probably will be again with 
kde5 once I can actually get kwin5 working long enough on my hardware[1] 
and eventually find kde5 stable enough of a base to run live again.

So marking ebuilds that can use ninja successfully and automating it so 
people that want to can, great, and by all means, document it well so 
they know they can, but please, gnu make default for now.

---
[1] kwin5 working: I've tried several times over the last year, always 
getting the same kwin5 crash/respawn loop and thus being unable to get 
any further into kde5 testing. FWIW single-card radeon turks graphics, 
triple monitor, native kernel/mesa/xorg driver, works fine with kwin4 in 
OpenGL mode.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages

[hasufell]

On 06/07/2015 05:08 PM, Michał Górny wrote:
> Hello, developers.
> 
[...]

It's not clear to me how the transition should look like.

Are you suggesting Ninja to be the new default or do you want to switch
per-packages after having tested them?

If the former, then we need a tinderbox-run.

Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Dnia 2015-06-08, o godz. 12:46:42
hasufell <hasufell@gentoo.org> napisał(a):

> On 06/07/2015 05:08 PM, Michał Górny wrote:
> > Hello, developers.
> > 
> [...]
> 
> It's not clear to me how the transition should look like.
> 
> Are you suggesting Ninja to be the new default or do you want to switch
> per-packages after having tested them?
> 
> If the former, then we need a tinderbox-run.

The latter. We don't have the resources to do the former properly,
and the number of packages relying on GNU make is too large. Some
ebuilds will also need more extensive changes.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages

[Franz Fellner]

Michał Górny wrote:
> Dnia 2015-06-08, o godz. 12:46:42
> hasufell <hasufell@gentoo.org> napisał(a):
> 
> > On 06/07/2015 05:08 PM, Michał Górny wrote:
> > > Hello, developers.
> > > 
> > [...]
> > 
> > It's not clear to me how the transition should look like.
> > 
> > Are you suggesting Ninja to be the new default or do you want to switch
> > per-packages after having tested them?
> > 
> > If the former, then we need a tinderbox-run.
> 
> The latter. We don't have the resources to do the former properly,
> and the number of packages relying on GNU make is too large. Some
> ebuilds will also need more extensive changes.

You have your userbase ;)
In order to reach as many as possible you could create a news item. Or a 
mailing list post. Ask them on planet.gentoo.org ;) Tell them how good ninja
performs :)
Ask them to set the generator to ninja in their make.conf to test if their
packages still compile. They create bugs for failing packages and you can
easily hard code good old emake in the specific packages.
As default there probably should always be emake. IMHO a working build system
always is better than a fast but potentially broken one :)

> 
> -- 
> Best regards,
> Michał Górny

Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages

[hasufell]

On 06/08/2015 02:01 PM, Michał Górny wrote:
> Dnia 2015-06-08, o godz. 12:46:42
> hasufell <hasufell@gentoo.org> napisał(a):
> 
>> On 06/07/2015 05:08 PM, Michał Górny wrote:
>>> Hello, developers.
>>>
>> [...]
>>
>> It's not clear to me how the transition should look like.
>>
>> Are you suggesting Ninja to be the new default or do you want to switch
>> per-packages after having tested them?
>>
>> If the former, then we need a tinderbox-run.
> 
> The latter. We don't have the resources to do the former properly,
> and the number of packages relying on GNU make is too large. Some
> ebuilds will also need more extensive changes.
> 

I'm not sure if it makes sense to add additional complexity, but another
approach could be done similar to the git shallow clone situation... as
in: the ebuild wouldn't say which Makefile generator to use, but which
ones work. The default would be: all work. That will expose ninja bugs
to our bugtracker.

[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Martin Vaeth]

Franz Fellner <alpine.art.de@gmail.com> wrote:
>
> IMHO a working build system
> always is better than a fast but potentially broken one :)

Meanwhile, it is not so clear which of the two systems
is more likely the "potentially broken" one:
According to some of the mentioned bugs, it appears to me
that some upstreams consider rather ninja as the "working"
(and well-tested) tool, and Makefile as poor man's fallback.

Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

Hi!

On Sun, 7 Jun 2015 17:08:57 +0200 Michał Górny wrote:
> Hello, developers.
> 
> As you probably know already, CMake sucks a lot. One of its more sucky
> features is that it generates Makefiles that fail a lot. In particular,
> they fail at verbose build logs that are cluttered with useless CMake
> intermediate commands and hard to read. But also they sometimes
> deadloop hard in faulty dependency scanning [1].
> 
> Those two issues can be solved by switching CMake to use Ninja instead
> of make. As you may know, Ninja is the fancy building tool that is
> faster and much harder to use than make. However, it integrates with
> CMake much better and with less hackery. In particular, the verbose
> build log is free of useless CMake percentage printing output and other
> non-sense, and contains only real build commands. It also gets
> dependency scanning right.
> 
> Sadly, there are two problems with using Ninja:
> 
> 1) it will not work with some packages,
> 
> 2) it introduces an extra dep (on Ninja).
> 
> The first issue is a bit complex. Sometimes the problem lies in CMake
> itself (not all CMake magic works in Ninja for some reason), sometimes
> in the project (relying on Makefile stuff), sometimes in the ebuild.
> For example, with Ninja you can't do '-C subdirectory' to run targets
> from a specific subdirectory. So, we can't force Ninja everywhere.
> 
> The second issue is a bit easier. GNU make is part of @system, ninja
> would be considered an extra package being installed. Do we consider it
> fine to require it randomly? Or do we need to justify the extra dep by
> benefits of building a particular package with Ninja? Is sane verbose
> build log a good enough benefit?
> 
> So, what do you think? Should I start switching random packages to
> Ninja whenever it works?
> 
> Oh, and this would be done via something like:
> 
>   : ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
> 
> before inherit line. To respect user forcing another generator, and to
> get deps right.

Sounds great. IMO default value should be determined per-package:
if upstream recommends Ninja (or there is a good testing with
Ninja), then set it, otherwise emake.

Any progress here? The only package in tree which allows user to
select cmake backend is llvm-9999.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Johannes Huber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am 06/07/15 um 17:08 schrieb Michał Górny:
> Hello, developers.
> 
[snip]

> Sadly, there are two problems with using Ninja:
> 
> 1) it will not work with some packages,
> 

[snip]

> 
> So, what do you think? Should I start switching random packages to 
> Ninja whenever it works?
> 
> Oh, and this would be done via something like:
> 
> : ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
> 
> before inherit line. To respect user forcing another generator, and
> to get deps right.
> 
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
> 

FYI we have a tracker bug now[1]. Bug alias is "ninja-porting" Toralf
Förster is already tinderboxing it. If we have all bugs fixed we can
discuss to enable it globally.

[1] https://bugs.gentoo.org/show_bug.cgi?id=557992

Kreetings
- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJV1QcfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0v80oP/22dI/4S0b36oxM+fKwh13a+
6Q9RMflwZtd+OKLPaeqZEU3XS2E/F0r8WR/GDWzZuRRFpJbOXjVjaB+GwEwrvi7V
t5bN8Xu8wTMuACEc8RbJWl1WClnEm8pEyODutdwXaePSt+w4cIOivdNZopzdkgFD
LkNAMk7wbsb4RNnbdpcmIXEFn0SSZvV52B8nof9l1XMhPgwYACa2E7PyY/uVzWae
nP1NfZLM8HRI9S41+jS4hDdrpIls03XBvdcEZfDZ3Wiru5ibXEcyYcSbjzvNlUpp
N+wCSjbtawjVuWF/h/ltW07EXtJEqlz0PrdW2P6rf1H7G8Z0vmzLGPh1LJ4cOVYH
cTMmEagQJjKiQnv1z+ijJrpsEVAAerApVpcEtoDmFFSwjxgEr34dGlNETrTWAB8x
vv14aVp94T+o5satjNQSeB6jyPySO4slTEYlZ2NZpX50oelF1aUgX4glaxadU0Yb
5Nd+xu4W7eeZf1TJ/DNTx8kHOEHnGzff/JZ+4+tUrtR/V61fHGPWrFRmiBC2U2Br
HjdaCefWE+lEbJm81a4LH0k7S0axMPZQHCuuicUt3uy2eNxJpBOMMDe0xGfzadZ1
c26sJgU6SdQhGSwMy6PiQGYw8AY9ffQk7KTfGiX5E4oMiiWXGDTU6jschqw4+ZlI
45qYstN0xi7VeAut8uYJ
=6/bq
-----END PGP SIGNATURE-----