Gentoo News

The Gentoo Council held a meeting on March 26, 2009. The items discussed were:

Technical issues:

• GLEP 55: Petteri Räty noted that portage had recently gotten support for both GLEP 55 and the parse-eapi proposal. Petteri will have benchmarks done by the next meeting.
• EAPI-3 Proposals: A call for objections to/questions about any of the various proposals was asked for. What follows is a list of proposals to which objections were raised or for which there are open questions as well as who raised the points.

• slot operator support: leio, open questions, position pending on answers
• default_src_install: Mart Raudsepp, Donnie Berkholz, Tobias Scherbaum, open questions
• doinclude: Donnie Berkholz, Mart Raudsepp
• dosed: Donnie Berkholz
• unpack failing on unknown types: Donnie Berkholz
• docompress: Mart Raudsepp, needs to review proposal and prepalldocs. Tiziano Müller, thinks it's useless
• doexample: Tiziano Müller, thinks it should have -r if we have it at all
• dohard being deprecated: Mart Raudsepp, thinks it should remain and have its bugs fixed.
• disable-dependency-tracking: Luca Barbato, possible breakage of configure scripts (mplayer & ffmpeg mentioned)
• utility commands should die by default: Mart Raudsepp, open questions
• ban || ( foo? ( . ) . ): Mart Raudsepp, sees no reason to ban something that might have some valid use cases

One part of the EAPI-3 discussion is whether to have variables that behind-the-scenes control the default functions. The DOCS variable was created so that a list of documentation to install can be passed to default_src_install. A 4-2 vote approved the DOCS variable for use in src_install. Specific details have not yet been worked out.

Open floor:

Ned Ludd requested that the council discuss a migration of KEYWORDS out of ebuilds to be discussed at the next meeting.

Summary

Gentoo is made up of 243 active developers, of which 42 are currently away. Gentoo has recruited a total of 685 developers since its inception.

Moves

The following developers recently left the Gentoo project:

• None this month

Adds

The following developers recently joined the Gentoo project:

• Lars Wendler joined the Bugzilla team

Changes

The following developers recently changed roles within the Gentoo project:

• Caleb Tennis left the KDE and Qt teams
• Matteo Azzali left the KDE team
• Stefan Schweizer left the KDE team
• Arfrever Frehtes Taifersar Arahesis joined the Python team
• Mounir Lamouri joined the VOIP team
• Gordon Malm joined the Ruby team
• Tony Vroon left the PPC64 team and joined the Xfce team

Summary

Gentoo is made up of 242 active developers, of which 42 are currently away. Gentoo has recruited a total of 684 developers since its inception.

Moves

The following developers recently left the Gentoo project:

Note: The number is higher than usual because several inactive developers were retired as per Gentoo policy. This operation is performed on a regular basis by the Undertakers project.

• Fernando J. Pereda
• Joshua Nichols
• Christian Marie
• Martin Ehmsen
• Anant Narayanan
• Vic Fryzel
• Chris Henhawke
• Michal Kurgan
• Ali Polatel
• Aggelos Orfanakos
• Saleem Abdulrasool
• Joshua Ross
• Matt Fleming
• Marius Mauch
• Sven Vermeulen
• Jan Hendrik Grahl

Adds

The following developers recently joined the Gentoo project:

• George Kadianakis joined the kernel team
• Arfrever Frehtes Taifersar Arahesis joined the crypto team
• Vadim Kuznetsov joined the Scheme team
• Christian Ruppert joined the Sunrise project

Changes

The following developers recently changed roles within the Gentoo project:

• Tony Vroon joined the VOIP team
• Nirbheek Chauhan joined the Mozilla team
• Thilo Bangert joined the vserver team
• Alexey Shvetsov joined the sci-chemistry and Xen teams
• José Luis Rivero left the Alpha team
• Markus Rothe left the PPC team
• Andrew Gaffney joined the LiveCD team
• Nicholas D. Wolfwood joined the LiveCD team
• Jeroen Roovers joined the LiveCD team
• Peter Volkov joined the LiveCD team
• Jesus Rivero joined the accessibility team
• Patrick McLean joined the Python team

Note: the original announcement was made March 12 by Raúl Porcel.

In the effort of expanding our support to embedded architectures, the Gentoo ARM and SuperH/SH teams would like to announce that we'll be doing autobuild stages like all the other architectures.

On the ARM side, we are currently doing stages for the following CHOSTs:

• arm-unknown-linux-gnu (old ABI, in progress)
• armv4l-unknown-linux-gnu (old ABI, in progress)
• armv4tl-softfloat-linux-gnueabi (EABI)
• armv5tel-softfloat-linux-gnueabi (EABI)

We would like to thank QNAP Inc. and Marvell Technology Group for providing us with support and hardware. However we would like to expand our support to the armv6 and armv7 processors, therefore if any vendor could provide us with some hardware it would be greatly appreciated. Please contact the Gentoo ARM team if you or your company are able to help us.

On the SH side, we are doing stages for the following processors:

• sh4
• sh4a

We would like to thank Renesas Technology Corp., which has provided us with SuperH hardware and support.

Due to the nature of these architectures, we'll be doing monthly or bi-monthly stages, as they take several days to build. The stages are available under the /releases/arm/autobuilds directory for ARM and /releases/sh/autobuilds for SH at your favorite mirror.

Also if you would like to talk about Gentoo on those architectures, please join us on #gentoo-embedded @ irc.freenode.net.

The London Internet Exchange (LINX) is a mutually owned membership association for operators of Internet Protocol networks. LINX is the largest neutral internet exchange point in Europe, and is also the most connected exchange point in the world, reaching out to 46 countries. Its network traffic is around several hundred gigabytes per second. Those are impressive credentials in and of themselves, but did you know that LINX also runs Gentoo on its servers? If you're on the internet, sooner or later your traffic will run through its hardware.

Hugh Spencer, IT manager for LINX, has graciously contributed this article on Gentoo at LINX.

---

LINX (London Internet Exchange Ltd.) servers are nearly all Gentoo-based. While Gentoo isn’t the easiest distribution to deploy, we have chosen Gentoo because of the level of choice and control it gives us. We have also used the Hardened Sources kernel to give us an edge when it comes to security choices.

So how did we end up choosing Gentoo?

Several years ago our previously favoured distribution decided to change its licence model and it wasn't clear that such a move wouldn't prove damaging for it. We decided it was time to investigate what the alternatives could offer us. The then-shiny new distribution called Gentoo seemed to fulfill most of the requirements in that it allowed us to make a lot of choices about what we included and didn’t include.

LINX isn't exactly a cash-strapped organisation even if it is a "not-for-profit" company, so why do we favour open source for most of our requirements? It really boils down to a judgement that the company is better served by utilising open source operating systems and applications in most cases. LINX is probably the most connected public network on earth. So we need to be pretty sure that servers are secured as well as they can be and that any exploits are patched as quickly as is humanly possible. Well-supported open source code tends to win on both these counts over the proprietary products on offer.

We like to be able to:

Verify that what we are proposing to use is fit for purpose.

We were once offered a proprietary mail handling product for free. Without access to source code it wasn’t easy find out how secure the product really was. However, after running Valgrind against the product we found it to be using deprecated libraries and rejected their kind offer on security grounds. An open source mail system is constantly exposed to scrutiny and its developers know this and act accordingly.

Modify the source code to suit our purpose.

An example of this is SugarCRM, which is designed to be customised. Every company has different requirements of its customer relationship management software. For LINX this is never a straightforward customer relationship since our membership can also be suppliers, some members having multiple identities and so on. In house customisation becomes the main feature of our work in this area. The trick is to maintain compatibility and feed back ideas to the developers.

Where we did choose proprietary code over open source was the Marratech video conferencing server - still on Gentoo. It won because its functionality was head and shoulders above anything else around in 2004. Sadly, the source code and its developers were bought by a big company who haven't done anything with it. Since both Linux and Mac operating systems have moved on, only Windows XP clients still work with it. While we gained by having a good product in the short term, we are now out in the cold looking for a replacement because we have no access to the proprietary source code. So far, both open source and proprietary solutions examined do not measure up to a product stalled in 2006!

Work with the open source community.

Having the source code open and available means that we are not only able to contribute but over time also have the opportunity to nudge the direction of a project if we feel it is straying off course. This occurred in the Linux kernel, just before version 2.6.26 was released.

Linus Torvalds releases regular release candidate kernels which we test on various hardware. For WiFi networks, the regulatory framework (which controls where in the world a certain radio channel is available) was rewritten from scratch. Unfortunately, only a United States zone and a Japan zone were defined. This left people in Europe in the cold, as Japan allows too many 2.4GHz channels (14) and US does not allow enough (11).

Transmitting on channel 14 would be illegal, so users were explicitly advised against doing this. To make matters worse, on the 5GHz band the US zone are mostly in line, but the Japan allocations are on completely different frequencies. As such, there was no way to have both channel 13 on 2.4GHz and networks on 5GHz available at the same time.

Gentoo developer Tony Vroon of LINX read the 1200-page 802.11-2007 WiFi specification and ETSI 301 893 and then contacted wireless developer Johannes Berg with a patch. This patch made it into the final 2.6.26 kernel before it was released to the general public. This meant that several Linux users did not lose access to their WiFi networks.

---

Your editor had the opportunity to ask Hugh some specific questions about Gentoo and LINX:

What are two of the most awesome things about using Gentoo?

1. The hardened-sources kernel

What would be awesome would be if the best of hardened kernel features could make it into the main stream, however we are aware that there are fundamental disagreements about doing this and many stumbling blocks in the way.

Over the years, the improvement in the interface and amount of help information immediately to hand in the menuconfig has made it easier to choose the appropriate options when installing a kernel source.

2. Vanilla packaging of upstream software

We like the way Gentoo packages upstream software with as little change as possible. Keeping packages in a "vanilla" state makes it easier when seeking support or talking to upstream developers. This approach is
something we value since we sometimes find ourselves conversing with developers about the way things work or don't work.

When it comes to patching, epatch is a lifesaver. However, we prefer to push patches upstream where it makes sense to do so. Gentoo is pretty good in this respect in that you can know if your patches make it or not and why. Further upstream things can get disheartening. Submitting patches can be like throwing them into a black hole with little or no feedback from people and organisations that have forgotten the ethos of
open source.

Where would you like to see Gentoo go? Where does Gentoo fit in your future?

We appreciate the open door policy on the #gentoo-dev, while it may not allow the general public to comment, the fact that it is possible to see what is exercising the minds of the developers gives us early warning over issues that may affect us.

A conclusion one can draw is that not only should the code base be open to scrutiny, the processes used to create and manage that code base need to be open to scrutiny. People are more likely to be loyal to a
distro they can see is trying to work in an open manner. So for the future; Gentoo needs to make sure it remains as open about itself, its direction and progress, as it does about the code it uses.

Many thanks to Hugh for contributing this article. We hope that Gentoo can continue to serve your needs!

The Gentoo Council held a meeting on December 11, 2008. The items discussed were:

Technical issues:

• Label profiles with EAPI for compatibility checks: Should there be labels in the profiles telling package managers what EAPI the profile uses. This proposal raised some concerns that developers would modify current profiles and bump the EAPI which would harm users' systems.
  Conclusion: Profile EAPI files are approved for use in gentoo-x86 profiles. The file for use in profiles is eapi. All current profiles are EAPI="0" and only new EAPIs can be marked with the profile EAPI markers. Any developer profiles can be marked with a new EAPI.
• Retroactive EAPI change: Call ebuild functions from trusted working directory. Donnie (dberkholz) commented that it may not be needed to add something to EAPI=0 that is in all the package managers.
  Conclusion: Approved. This change applies to all current EAPIs (0,1,2).
• Metadata variable for DEFINED_PHASES:
  Conclusion: Approved. Infra will do a full regen of the metadata cache once Portage has support for it.