Google Summer of Code 2010 ideas

From Gentoo Linux Wiki

Jump to: navigation, search

Want to spend your summer contributing full-time to Gentoo, and get paid for it? Gentoo is applying for its 5th year in the Google Summer of Code. In the past, almost half of our successful students have become Gentoo developers, so your chances of becoming one are very good if you're accepted into this program.

Contents

[edit] For Students

Most ideas listed here have a contact person associated with them. Please get in touch with them earlier rather than later to develop your idea into a complete application. You can find many of them on Freenode's IRC network under the same username. If there is no contact information, please join the gentoo-soc mailing list or #gentoo-soc on the Freenode IRC network, and we will work with you to find a mentor and discuss your idea.

You don't have to apply for one of these ideas! You can come up with your own, and as long as it fits into Gentoo, we'll be happy to work with you to develop it. Remember, your project needs to have deliverables in less than 3 months of work in most cases. Be ambitious but not too ambitious ;)

Applications are now open -- the earlier the better, but don't rush through it! We have a custom application template that we will ask you to fill out. Here it is:

Congratulations on applying for a project with Gentoo! To improve your chances of succeeding with this project, we want to make sure you're sufficiently prepared to invest a full summer's worth of time on it. In addition to the usual application, there are 2 specific actions and 1 piece of info we would like to see from you:

  • Use the tools that you will use in your project to make changes to code (e.g., source code management [SCM] software such as CVS, Subversion, or git). Please use the same SCM as you will use for your project to check out one of our repositories (more repositories), make a change to it, and post that change as a patch on a mailing list or bug. You don't necessarily have to fix any real bugs; this is to show that you can use the tools. Your contact in Gentoo can help you determine which SCM and repository you should use for this. If your idea doesn't have a contact, please get in touch with us on the gentoo-soc mailing list or in real-time on IRC at Freenode/#gentoo-soc. Once you've made your change, link to it from your application.
  • Participate in our development community. Please make a post to one of our mailing lists and link to it from your application (archives.gentoo.org holds past postings). The gentoo-soc list would be a good starting point, if you aren't subscribed to any others already.
  • Give us your contact info. Please provide your email address, home mailing address, and phone number. This is a requirement and provides for accountability on both your side and ours.

These actions are things you will do extremely commonly as an open-source developer, and they really aren't that hard, so don't let them hold you back! The remainder of the application is free-form. Please read our application guidelines and Google's FAQ to complete it. Good luck!

[edit] Ideas

NOTE: Discussions about these ideas should take place on the gentoo-soc Mailing List (CC the contacts if required). Please go through the existing discussions about your idea in the mailing list archives before posting.

[edit] gentoo-x86 QA website

The idea is simple enough, take the QA results from various tools and present it via a searchable website. Think packages.gentoo.org, just for QA results. The implementation work required would primarily be building the website itself- the user could rely upon pkgcore-checks for the initial data stream (it can output it's results as a pickle stream) leaving the candidate to focus on generating a site providing insight into the status of current architectures, current stabling, etc.

One additional constraint would be that the underlying DB schema should be written in a fashion that allows multiple data imports to be used- while pkgcore-checks right now can provide data for a candidate to work with, the candidate should be designing a system also able to pull in other data sources (at some point repoman for example).

Finally, an additional feature could be designing the underlying schema and website to allow for the possibility of being able to handle multiple repositories- think about if the gnome herd wanted their overlay to be scanned/accessible. This complicates the design a bit (specifically keeping it fast), but is likely to be desired functionality down the line.

The relevant gentoo-soc discussion (with a bit more details) is accessible on in the gentoo-soc archives

Skills:

  • python (data importation)
  • web frameworks- this includes some html/css/JS knowledge, depending on how complex the candidate wishes to make the site
  • RDBMs schema design.

Contacts:

[edit] libbash

Repoman could do multiple checks using a bash AST instead of relying on regular expressions etc. Portage implementation itself would be more efficient if it could interface with the implementation using method calls instead of the current hacks. Can be either done from scratch or working with bash upstream to get this stuff there.

Skills:

  • bash
  • c/c++
  • parsers

Contacts:

[edit] Council web application

Finish the work I started on Gentoo council web application. The more council related functions like agenda handling and voting the application supports the better. The goal is to improve Council operations and not just implement for the sake of it. For information on features see http://archives.gentoo.org/gentoo-council/msg_a1f5b963f108692770c2c8ea8d082d3e.xml

Skills:

  • rails

Contacts:

[edit] Improve NetworkManager integration with Gentoo

People who use NetworkManager in Gentoo have found that it lives in an ecosystem of its own, completely detached from the network configuration in Gentoo (/etc/conf.d/net, hostname, dns, etc). Due to these reasons, the init script has not even been made to "provide net" yet, which makes it quite useless out of the box. However, NM is an excellent tool, and the aim of this project would be to make it work properly in Gentoo.

This mostly involves writing a NetworkManager plugin to read and write to Gentoo configuration files, and various other improvements to enhance integration. Creating a full list is left as an exercise for the applicant.

Skills:

  • C
  • GObject C
  • Basic understanding of networking
  • Familiarity with network configurations and services in Gentoo

Contacts:

[edit] Centralized maintainer helper website

The long-term goal is a central website that package maintainers can visit, in addition to bugzilla, to easily find out what maintenance related tasks are there to be done specifically by him/her. More background and goals can be found at the unofficial project page: http://dev.gentoo.org/~leio/grumpy/ (might slightly grow content during the application period).

As the whole project is rather vast and longer term, the intention of the summer project could be to get the global infrastructure implemented in a way suitable for the different future types of report/data source modules, together with some basic proof of concept "modules" showing that the infrastructure is indeed suitable. Parts of the global infrastructure are for example user matching with their maintained packages (to show only relevant tasks by default); central database of packages that modules can tie to (and in turn to the maintainers); potentially infrastructure for interacting with command line tools; central website views/design, and so on. Another possibility is to implement a few "modules" more fully, while keeping an eye on being able to tie them, and future ones, together into a centralized site. These are just examples; the proposal shall list in more detail what can be achieved within the timeline. Suggestions on how could the long-term project proceed after the goals of the summer project have been achieved are also appreciated, showing that the long term goal of a "one stop shop for maintainers" has been kept in mind.

Skills:

  • Web technologies (preferably in Python, concrete modules or frameworks can be discussed/agreed during application period)
  • Relational databases and their schema design
  • Basic web design
  • Data mining (in case of some modules)

Contacts:

[edit] Add "tags" support to Portage

Gentoo uses categories now. A package can only be in a single category, which is very limiting because generally things don't fit perfectly into one place without other possibilities. Tags could make it a lot easier to find packages they're looking for by doing Boolean searches like: kde AND mail. This project would add support for tags to Portage and would allow for backwards compatibility of categories as tags.

Note: This project in its current form is considered trivial and not suitable for a complete SoC project [1]. If you wish to work on this, you should expand the idea significantly.

Skills:

  • Python

Contacts:

  • Your name here.

[edit] Portage/ebuild ability to use file-based capabilities rather than setuid

With recent Linux kernels, file-based capabilities are available. It is thus possible to give the ping command just the minimum capabilities needed to access the RAW socket, rather than leaving it entirely setuid. A long term goal for Gentoo would be to allow the user to choose capabilities over setuid for (at least some) programs. To support this feature however, Portage needs a means to copy over capabilities from one file to another. A python extension may be needed to handle this.

Skills:

  • Python

Contacts:

[edit] Fastboot on Gentoo

A few months ago, some kernel developers working at Intel got boot times on solid-state drives down to 5 seconds (10 on hard drive). It would be awesome to have this in Gentoo. This would require significant changes to our custom init system, OpenRC, as well as lots of profiling of the kernel boot and userspace boot processes using tools like bootchart. More info about fastboot is here. Note that the work of fastboot was primarily concerned with:

  1. sreadahead, for which there already are packages in the tree, and
  2. optimizing the init system (which might be a bit tough for OpenRC).
  3. optimizing the services in the init system (easier)
  4. asynchronous kernel function calling (in 2.6.29)
  5. speeding up loading of the desktop environment (early GDM start, profiling etc)

NOTE: There have been a large number of applicants for this idea, and a lot of discussions about this on the mailing list archives. Because of this, we have decided to raise the bar for this idea. Applicants expecting to get selected should show us their capability by plucking some of the low-hanging fruit (aka, easy fixes) in the boot process. Show us the code.

Skills:

  • Shell scripting, C

Contacts:

[edit] Upstart on Gentoo

Related to the Fastboot objectives, it has been suggested that Upstart could be modified to support the Gentoo init.d scripts, which already provide nearly all the same metadata required for upstart scripts. This would enable drop-in use of upstart on Gentoo, without rewriting any init.d scripts. It would be used in conjunction with OpenRC, and not be a replacement for OpenRC. This will require modifications to both OpenRC (so it can use either SystemV init or upstart) and upstart.

Skills:

  • Shell scripting, C
  • A solid understanding of Gentoo init.d scripts.

Contacts:

[edit] Port the new distro-neutral initrd framework, Dracut, to Gentoo

Instead of every distro having its own way to generate an initramfs, many people would like this to ship with the kernel. It's developed primarily by Red Hat with a fresh start and thought put into portability. See this LWN article for more info.

Skills:

  • Shell scripting

Contacts:

[edit] Make the clustering LiveCD from a previous GSoC bootable from USB

The clustering LiveCD is a bootable image that allows you to instantly turn a full room of computers into a functional cluster. You only need one CD because the rest of the nodes boot disklessly from the master node with the CD. This project would be a huge improvement to the existing version because it will allow us to use persistent, writable USB media instead of a read-only CD. That means clusters won't need to be reconfigured from scratch on every boot. That will save a lot of admin time on each boot and make it possible to do things like run a cluster in 10 different computer labs with different settings on each, as easily as inserting 1 USB stick in each lab and rebooting all the computers.

Skills:

  • Shell scripting, maybe some Python

Contacts:

[edit] BSD ports of Gentoo: OpenBSD, DragonFlyBSD, etc.

We've never had a DragonFlyBSD port, and the OpenBSD port is dead. This project would involve investigating and implementing the necessary porting work to get a Gentoo userland running on a BSD kernel and base system (the base system is also managed by Gentoo).

Skills:

  • Shell scripting, C (patch creation)

Contacts:

[edit] EBuild generator

For the basics, writing an ebuild could be some pythonish gui thing to get stuff like dependencies and some common code blocks in there. Plus it's easier if you don't need any special overrides. One attempt to create such a tool was Abeni.

Skills:

  • Python

Contacts:

  • ? (Your name here)

[edit] Cache sync

The portage tree and all its overlays keep growing. Right now only the official portage tree occupies more than 600Mb on a regular filesystem. However the package manager does not need the whole tree of full ebuilds, patches and manifests to perform most of its work. The idea would be to sync a smaller database or a cache of only needed information for global package manager operations, then fetch the required package only when needed. It would speed considerably tree synchronization and reduce the space occupied by portage tree (see the "Repository of Self-Contained Ebuild Source Packages" idea for an alternative approach). Currently the cache system in portage is also really slow and so is the search feature. The project could be inspired by the Debian or RPM system but with the usability and choices offered by Gentoo, and would probably include:

  • design and implement automatic cache builder to be produced by a given repository/overlay
  • make portage/paludis/pkgcore to do delta-sync with a local cache and fetch only the required files to be installed when requested

Skills:

  • Python (portage/pkgcore) or C++ (paludis)

Contacts:

  • Your name here.

[edit] Improved binary package support

Portage lacks a few features that would make binary package support much smoother and less prone to breakage, which would make Gentoo better for derived binary distros. One of them is more intelligent handling of library versions with binpkgs. Basically, it's possible to build a binpkg against an old version of a library, then install it against a new version and have it be broken by default because of a shared-library version bump. Ideally, a package would have a way to specify which exact files it depends in the built state on instead of just which versions it can build against from source. See bug #192319. Another problem is saving binpkgs with different USE flag and other build settings on the same host. See bug #150031. The way forward is one or more hashes of the metadata. A third problem is the lack of binpkg support for the kernel. This could be changed through modifying the kernel eclass to support a binary USE flag that also did configuration & build, or perhaps some kind of genkernel modification, or both. See bug #154495.

Skills:

  • Python, shell scripting

Contacts:

[edit] Shape up linear algebra, FORTRAN, and make benchmark suite

Quite a few numerical libraries are available in Gentoo (BLAS, LAPACK, FFTW,...). Many of them need FORTRAN compilers, and are offered in various implementations. The work could consist of shaping up our numerical libraries, adding possibly others, robustifying our flaky selection mechanism also for any combination of compilers, versions and dependencies, allowing user switches, and finally write up various benchmarks and test suites. Users could very easily select the most accurate and fastest libraries and compilers of their choice.

Skills:

  • Shell scripting, packaging, compilers, numerical libraries knowledge.

Contacts:

[edit] Write G-PEAR (inspired by G-CPAN)

This project involves writing a tool (tentatively named G-PEAR) that generates and installs PEAR packages on the fly. The tool could closely emulate the structure of G-CPAN, that is open to discussion however.

Skills:

  • BASH/ebuild/eclasses
  • PHP

Contacts:

[edit] SCM snapshot management infrastructure

A growing number of projects provide binary-only releases of their packages with the source available only as a tag in a version control system. This presents obvious problems for source-based distributions, as we must provide one of two possible solutions:

  • live ebuilds, which pull the tag directly, making them vulnerable to a single point of failure (the upstream SCM server) and the possibility of upstream altering the tagged contents, as well as possibly placing an excess load on the upstream servers; or
  • snapshots, which must be pulled and manually packaged by a developer and hosted on Gentoo infrastructure. Snapshot archives are often not reproducible bit-for-bit and do not have upstream's direct "blessing".
Note: there's a third solution, which is to copy the scm tree and provide our own

This project would implement a Gentoo snapshot management infrastructure (an extension of Gentoo's existing mirror infrastructure) to provide a better alternative. The process would be:

  • The ebuild writer specifies a scm url and tag
  • If the writer has no access (the ebuild is not uploaded to main tree or a listed overlay), the ebuild behaves as a live ebuild.
  • Otherwise, the snapshot manager daemon packages the snapshot and posts it on Gentoo mirrors. The ebuild fetches the snapshot and uses it. (this will require a manifest update upon/after commit...)
  • The snapshot manager daemon periodically checks the sources of all snapshots for changes that would alter the contents of the snapshot. It alerts the ebuilds' authors to any such changes.

The coding part would involve writing the aforementioned daemon. The mentor would have to be someone from infra, or at least the student would be interacting with infra a lot.

Skills:

  • Likely Python or shell scripting

Contacts:

[edit] Adapt Kuroo for current portage versions

Kuroo made using Gentoo feel easy - just as it should. Finding and installing packages was very easy, as were most common maintenance tasks, like unmasking a testing ebuild or adjusting USE flags.

Sadly the Kuroo backend couldn't keep up with the pace of development of portage (for lack of time), so it doesn't work well with current portage versions.

Getting it working again and future proof would regain a great package manager GUI for Gentoo, opening Gentoo up for many new users, especially for people who had someone else install their Gentoo for them and now need a good GUI to maintain their Gentoo.

This project would involve:

  1. Adding/Fixing Kuroo support for newer Portage features
  2. Porting to QT 4 and KDE 4
  3. Finding and implementing a way to make it easy to maintain during future portage changes.

Note: Kuroo's original upstream is dead, and it has been migrated to sourceforge.

Skills:

Contacts:

[edit] Octave/Matlab support

Octave support could be really improved in Gentoo. Octave has now a core+plugin architecture. In order to facilitate the inclusion of octave-forge packages, an ebuild installer was created, similarly what is done for perl g-cpan G-CPAN, called g-octave, but this installer needs some improvements yet (extracted from the ToDo list):

  • Support to Python >= 3.0
  • Improve the use of g-Octave as a normal user, with "--pretend"
  • Improve the script that generates the package database
  • Improve the details available on the packages list
  • Write a testsuite
  • Support the update of the packages already installed
  • Support the installation of multiple packages at once (not only the dependencies)
  • Support to Paludis
  • Support to pkgcore
  • Logging g-Octave actions to a file
  • Support installation from the octave-forge SVN repository

Also there is still open work to integrate matlab programs compatible with octave such that one could use matlab or octave seamlessly. Some work was done by markusle last year on the science overlay the project could rely upon.

Skills:

  • Shell Script, Python, C++ if Paludis.

Contacts:

[edit] R packages ebuild generator or installer

Gentoo R users have to rely on R installer to install CRAN packages. The project would involve using Gentoo package manager to install one of the few thousands R packages. Paludis used to have CRAN support that the project could be based on, but doing a g-cpan like tool to generate ebuild would also be good.

Skills:

  • Likely shell scripting or possibly Python, C++ if paludis

Contacts:

[edit] Glendix: Create a lean distro based on Gentoo and Plan 9 (Glentoo?)

Glendix is a port of the Plan 9 userspace to the Linux kernel. In its current state it is just a set of patches to the Linux kernel to make sure Plan 9 binaries are able to run unmodified. However, in order to bring the entire Plan 9 userspace experience to Linux, we need a lightweight Linux distribution that packages all of this nicely. Gentoo provides us a great base for this because of it's customizability.

The objective of this project would be to create a LiveCD based on Gentoo and Glendix, providing the end user with a nice experience of Linux with a non-GNU (namely Plan 9) userspace.

Skills:

  • Catalyst
  • Likely Shell Scripting
  • General knowledge of how a Linux distro is put together, what the init process is and so on

Contacts:

[edit] Multiple Repository Support in sys-apps/portage

Be able to easily use overlays (without layman).

each repo should be able to have a differently defined way of sync-ing (within predefined standards), they should also be capable of defining the way that Manifests are handled (git doesn't need more than distfile manifests, other vcs may be similar). Supported repository types should include rsync, git, svn, hg, bzr, darcs, cvs. each SYNC_METHOD should be isolated from the others in code so that they can be improved/extended easily. Note that, due to bug #262038, multiple repositories that contain duplicate ebuilds (of the same version) tend to interfere with each other when there are differences in KEYWORDS.

Skills:

  • python
  • proficiency in multiple vcs'

Contacts:

[edit] Maven integration

Be able to easily write ebuilds for projects using maven.

The goal of this project is to be easily able to write ebuilds for upstream projects that use Maven as the build system. The work can either be finishing the work started in java-overlay or a new approach.

Skills:

  • Maven
  • basic Gentoo/Java understading

Contacts:


[edit] Gentoo/Java IDE integration

Be able to easily work with system libraries in IDEs.

Fix Netbeans or Eclipse so that they are easily able to find system installed libraries and their javadocs. Potentially work with the Package Kit integration project so that the system libraries could automatically be installed based in imports etc.

Skills:

  • Java
  • basic Gentoo/Java understading

Contacts:

[edit] Rewrite java-config in C++ or python

java-config needs a lot of new features and could use a rewrite as it has a lot of legacy from the generation 1 days.

We could drop the need of python for the Gentoo/Java tools if this is written in C++ but python can also be acceptable. Ideally the need for external libraries is kept to minimum.

Skills:

  • XML transformations
  • basic Gentoo/Java understanding

Contacts:

[edit] Visual Gentoo

Visual Gentoo (or Ventoo) is the intended graphical configuration framework for the Gentoo configuration files (yes, those inside /etc/conf.d/ mainly). Basically, the main idea behind Ventoo is to offer both an easy GUI building framework specifically tailored for Gentoo configuration files and also a graphical interface for the user to work around these files.

Ventoo was a Google Summer of Code project in 2007, and you can already get the tarball of it from the GSoC 2007 Gentoo download site , though most of the basic ideas are already there, the code is bit outdated and requires some work to make it functional.

This idea has the following goals for the summer:

  • Make Ventoo fully functional in current Gentoo systems and make it part of our distribution for this GSoC. (The code is bit outdated and is required some effort to make it more standard and functional for the end-user).
  • Support new configuration files and new kind of widgets in the framework.
  • Add new features. For example, it'd be nice to access init scripts from Ventoo too.
  • Any cool idea you could come up with :)

Skills

  • Python
  • PyGtk
  • Bash
  • Very familiar with the Gentoo configuration files.

Contacts

[edit] webapp-config rewrite

webapp-config is the web application installer and updater on gentoo. it currently has many issues and bugs, and its design has some serious flaws. fixing the current mess would a waste of time. instead it should be reimplemented, possibly in a distro-agnostic manner.

Skills

  • Python
  • Bash

Contacts

[edit] Web interface for submitting Documentation changes

People are often intimated by XML, and finding the "source code" to the documentation can be painful for people. So having a user interface to our documentation would help out a lot with contributions.

Workflow would be something like:

  • person visits documentation page
  • person notices a mistake
  • person clicks an embedded "edit" link
  • person makes the correction and hits "save"
  • proposed correction is sent to gentoo-doc mailing list

Sending to the mailing list would be the easiest way to integrate with current infrastructure and wouldn't require the person to create a bugzilla account just to submit a suggestion.

[edit] g-pypi rewrite

g-pypi is a tool to create ebuilds automatically from the Python Package Index. Currently, g-pypi has lagged behind portage development and needs some coding to make it work as great as it once did.

Skills

  • Python.
  • Familiarity with Gentoo Ebuilds.

Contacts

[edit] Distfile Fetcher Intelligence

The distfile fetcher interface has been static in Gentoo for a great many years now. There has been talk in the past about exporting more of the distfile metadata, to enable intelligence in the fetcher, but little progress has come of it. At the very least, this project would entail putting together a way to invoke an intelligent fetcher, so that it can be given multiple URLs, as well as checksums directly. The intelligent fetcher could be as simple as a wget wrapper, or as complex as constructing a Magnet link to use with an integrated BitTorrent client (for huge distfiles, possibly daemonized). Parallel fetching of parts of large files (from different mirrors) would also be easily supported by this.

The only parts of the Portage codebase that would need to be touched are the very small section that invokes the existing fetcher, so that it can export the data needed. The split is intended to make easy to apply this to other source distributions with similar distfile fetching needs.

Project breakdown:

  • Portage/package manager modifications to export the following data per distfile: output path, basename, all mirror URLs, all checksums
  • Potential "Intelligent" fetcher
  • potential modes for new fetcher:
    • Pick fastest mirror from available (for some definition of fastest: geographical, latency, hop-count, bandwidth etc)
    • Segmented HTTP fetch (like GetRight etc)
    • Peer-to-Peer, based on file hashes. Examine magnet links or other systems that use the hash of the file as a search key.
    • Ability to use existing CDN networks (eg CoralCDN)

Skills:

  • Portage modification: Shell scripting, Python
  • Outside application: any language

Contacts:

[edit] PMS compliance test suite

Right now there is no way to validate that a pkg manager implementation is compliant w/ what PMS specifies, nor any way to track what affects a spec change may have on the various managers w/out testing each.

The idea is simple enough; write a test suite that allows for plugging a package manager into it (whether it be portage, pkgcore, or paludis) and verifying PMS compliance. Most likely this would take the form of custom ebuild trees the package manager is told to operate on, but other approaches may exist.

Skills:

  • dynamic language of some sort for the test harness, and potential test case generation
  • bash
  • close attention to detail (this is implementing tests for spec compliance after all)

Contacts:

[edit] Repository of Self-Contained Ebuild Source Packages

This proposal is similar in scope to the Cache sync proposal, except that it will focus on implementing support for repositories that host self-contained ebuild source packages that are analogous to source RPMs (SRPMs). The repository layout will be similar to existing PORTAGE_BINHOST repositories (like those hosted at tinderbox.dev.gentoo.org), and will include a metadata index file which is similar to $PKGDIR/Packages. Each source package hosted in the repository will contain a single ebuild, its metadata, and all files it requires from the portage tree (including all inherited eclasses and any additional files such as patches from the files directory). A zip file will be a suitable container for one of these source packages.

A synchronization script will generate source packages from a source portage tree (or overlay), and it will avoid unnecessary regeneration of a given source package in cases when no relevant files have changed timestamps or been added/removed. This script will be run as often as the repository maintainer wants to synchronize with the source tree.

The syncronization script will have an option to preserve source packages that no longer exist in the source tree, perhaps updating such packages if they happen to contain outdated versions of eclasses. The ability to retain packages that no longer exist in the source tree may be useful for some cases of the stable tree idea which was proposed in GLEP 19.

In order to ensure that repository updates do not interfere with clients, it may be desirable to publish the repository as a series of snapshots that are contained in directories which are named corresponding to snapshot date/time. This will ensure that a previous snapshot is still accessible when a newer snapshot becomes available. So, clients will never have any trouble downloading a specific source package that corresponds to a metadata index which was downloaded earlier and used for a dependency calculation. Without some kind of snapshot mechanism like this (similar to RCU), a race condition would exist such that dependency calculations would be somewhat unreliable, and downloaded source packages might have different checksums and dependencies from those listed in a metadata index that was downloaded only a minute earlier.

Skills:

  • Python (portage/pkgcore) or C++ (paludis)

Contacts:

Retrieved from "http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas"
Personal tools