The main page is at SummerOfCode2012. This page contains the available projects, all the the projects should follow the following template: (Please do not add ideas of projects, suggestions without mentors, etc, only final projects for students to take.)


Title of the project


Create Lintian reports frontend

The static package analysis tool, Lintian, is currently being run on all packages in Debian. It has a tool called "harness" to publish the results of its quality checks on lintian.debian.org.

Currently, "harness" is an "internal" tool to generate these reports (static HTML pages), but we believe it would be useful to Debian as well as its many derivatives to have a proper tool for generating these reports.

The project is made up of two parts: the first (shorter, introductory) part is to create a black box test suite to test the current harness tool. The second and most time consuming part is to rewrite "harness" into a proper tool that is usable without a pilot license.


Provide an alternative to libstdc++ with libc++

Within the context of the LLVM project, a new implementation of the C++ standard library (header + abi) has been developed: http://libcxx.llvm.org/ & http://libcxxabi.llvm.org/

The goal of this project is triple:

  1. Port the libc++ to Debian (GNU/Linux as a first target, maybe Kfreebsd/hurd later)
  2. Provide libc++ as a Debian package.
  3. Provide a way to switch between libstdc++ to libc++ and vice-versa

Please note that the project might be more a proof of concept and the final results might not be included into the archive.


Improving Debian Team Activity Metrics

The ''Debian Team Activity Metrics'' was started as a Google Summer of Code 2011 project by Andreas Tille (mentor), Scott Howard (co-mentor) and Sukhbir Singh (student) to measure the performance of teams in the Debian community by inspecting postings on relevant mailing lists, commit statistics from project repositories and package upload records from the Ultimate Debian Database.

Though we have developed tools that fetch the required data for the metrics described above, there is no interface to access that information. Your job will be to:

Also, if time permits, there are other improvements to be made that will make the project complete, such as implementing new metrics, verifying the veracity of existing tools and optimizing the code.

A sample of our work (external links to imgur.com):

  1. Mailing list activity
  2. 'Team Metrics' Git repository activity

So the aim of this project is to make the above information accessible through a web interface. Note: The data is ready, you just have to create an interface and present it nicely.


clang support for build services

The idea of this project is to extend the Debian infrastructure to be able to build packages with clang instead of gcc/g++. clang has some advantages over gcc/g++ like better error messages and better warnings.

Even if the short/mid term goal is not to replace gcc/g++, building packages with two compilers (or more) improves the detection of C/C++ or Objective C errors, which in turn helps improve the quality of the distribution, even if the packages continue to be compiled with gcc/g++.

A first study has been published clang.debian.net Announce A LWN article about this subject.

Results of http://clang.debian.net have been obtained through a sbuild image with some minor modifications.


Semantic Package Review Interface for mentors.debian.net

Debexpo (the software running on mentors.debian.net) is a collaborative package review tool. Debian, as a community distribution, allows everyone to maintain packages in the archives. New contributors are supposed to go through a mentoring process, which - among other things - involves package reviews by more experienced members of the community. Debexpo helps with this review process, allowing anyone to upload prospective, request a review, and eventually, to request sponsorship to get the package uploaded to the official Debian archives by a Debian Developer.

Once uploaded to Debian, packages then flow into the many Debian-derivatives; the maintenance and inclusion of packages in Debian is thus central to the entire Debian and Debian-derivative ecosystem as highlighted by Ubuntu's "Debian First" policy. Recent discussions about package review systems have indicated that Ubuntu's current REVU system could be replaced by Debexpo in an effort to converge.

Thorough reviews of packages made by less experienced maintainers, before they're uploaded to the main package archive, are key to maintaining the technical excellence of the Debian distribution. Unfortunately, the lack of manpower for package reviews extends the length of the process to a point that it is a recurrent source of frustration in prospective contributors. This project aims to simplify the package review process by providing a semantic review tool for source packages on the http://mentors.debian.net/ website.

The main objective of the project would be to gather a new set of semantic metadata (e.g. an uploaded package is python-based, a package uses a certain packaging helper, ...) on packages uploaded to Debexpo, using the available Debian QA tools or ad-hoc heuristics. This new semantic metadata should then be matched to the interests of sponsors and teams, which would be taught to the software either automatically (by looking at the sponsor upload history) or manually (with a set of tags set by the sponsor). An automatic matching of sponsor and package traits should make the mentoring process easier and faster.

This new feature will need to be integrated with the current mailing-list and bug-tracking system based workflows.


Package an OpenStack use case


Multiarch Cross-Toolchains

Cross-toolchains are very useful, and have become more important recently due to the rise of ARM devices everywhere. Having them in the distro like any other tool is a real boon for development. Debian has multiarch (the ability to install stuff for multiple architectures at once) and it has cross-toolchains, but it does not have multiarch cross-toolchains, nor cross-toolchains in the main distro.

The Embedded Debian Project has made cross-toolchains available for many years outside the main Debian archive, but toolchains in the main distro would be much more convenient. This has not been possible until now because dependencies between architectures are needed. The new 'multiarch' feature enables this possibility. Enabling this will actually simplify the builds over what goes on now, and you have the opportunity to turn something kind of ugly into something much more beautiful. This sort of infrastructure work is fascinating, as it is the bringing together of many simple pieces into a complex whole, and if you get it working many people will really appreciate your work.

The first part of the project is showing that this build mechanism works. The second part is making sure that the cross-toolchain produced searches the new multiarch library and header paths by default, so that things built with it will build correctly. The final part will be working out what is needed to merge it into the central Debian build system, which does not currently cater for these cross-arch dependencies. You will get to learn how the mysterious inner working of distributions, and Free Software communities, actually work.


Port bootstrap build-ordering tool

Description of the project:

Bootstrapping new debian ports or rebuilds from scratch is extremely difficult, not least due to cyclic build-dependencies which mean that there are sets of packages where none can be built until at least one of the others is built. Work is ongoing to make this easier within Debian, by adding metadata to packages to allow 'staged' or 'bootstrap' builds (See 'Bootstrappable Debian' GSOC project). One of the necessary parts of the solution is a tool which can find the 'staged build' reduced dependency information within package metadata, and use that to break cyclic build-dependencies in order to generate a linear build-order for packages, including rebuilds of previously-staged packages as soon as it is possible.

Various aproaches of varying degrees of rigour can be taken to this problem. One based on edos-debcheck, a tool to analyse dependency satisfiability, is probably the 'right' way to do it. But it could also be done using python-apt and python-debian, building on what xdeb does. The tools would need to be taught to consider the Build-Depends-Stage1 info instead of the Build-Depends info in order to turn the graph into a tree. Then ensure that staged packages are rebuilt as soon as their normal build-deps are satisfied, and any other packages built against staged packages are also rebuilt to ensure consistency. Determining the optimum switchover point from cross-building to native building would be another useful feature.

Details of the staged build mechanism are here: http://wiki.debian.org/DebianBootstrap


SysV-init file creator from systemd service files

The goal of this project is to allow a migration away from SysV init in a smooth way while catering for the ports which still need SysV init for the foreseeable future.

The current problems of migrating away from SysV init are:

The idea of this project is to allow maintainers to maintain one single file (in the case for this project: the systemd service file) for all init systems (at least SysV init) and pushing the complexity out of most packages. As a bonus, the quality of the init scripts overall is quite likely to increase, since writing correct init scripts is quite hard.

There will be some SysV init scripts that will not fully fit into systemd service files, hence impose the maintainance of both a systemd service file and a SysV init script, essentially imposing parallel maintenance of two different files. This should be rare and usually only needed for the early boot services.


Pluggable acquire-system for APT

Package management is in large parts data management. The "apt" tool is currently only interested in packages and their dependencies and only downloads data related to this. But higher level tools need more content like information about files in a package (apt-file), tags (debtags), etc. There are is a multitude of tools related to package management now that download their own set of data with different commands (apt-get update, apt-file update, debtags update, …) and new developments like DEP11 require even more data. All using different backends to download.

The goal of this project is to provide a unified backend that the various tools can register into to provide the user with a good experience and is secure and bandwidth-efficient. So 'apt-get update' would replace all these extra acquire tools by allowing the others to declare which files they need and to provide them with "goodies" like hashsum checking (security), different supported (de)compression formats and pdiffs (bandwidth-effient).

deity@lists.debian.org, irc: #debian-apt


Bootstrappable Debian

Debian is currently extremely difficult to bootstrap from scratch, which makes new ports and optimisations very difficult to do. The primary issues are breaking cyclic build-dependencies and the need to cross-build at least the initial set of packages. Work has been ongoing to first analyse and then design a fix this problem over the last year or two, but a lot of work remains to turn it into a practical reality. The design is described in http://wiki.debian.org/DebianBootstrap. The analysis at http://wiki.debian.org/CircularBuildDependencies

This project consists of doing the actual work of modifying packages to make optional the optional parts so that build-dependency cycles can be broken by building packages in 'minimal' form. These changes need to be made in an upstreamable way so they don't have to be done manually by every porter. In order to test the work you need to build modified build-tools that understand and use the extra fields, and in order to make it useful you need to make sure that the packages involved cross-build properly, using the new multiarch mechanisms.

This project is closely associated with the 'Port bootstrap build-ordering tool' project outlined elsewhere. The output of this work forms the test-data for that project, and the mechanism of this project is made automable by the output of that project. The two projects use each other's results, but both can also do their work independently. Both are required for a fully automated bootstrap.

http://wiki.debian.org/DebianBootstrap#line-106


Improve debian-installer network setup


Virtual Image creation web interface

The project goal is to provide an equivalent of Suse Studio for Debian, e.g. the possibility to create custom virtual images for the cloud.

The student will develop a web interface than could be used by non programmers to create custom images with desired packages and custom scripts launched at (first) boot. User will also be able to add their own data. The goal is to help people create their own Debian images for virtualization. Student would use grml-deboostrap for background generation and a python framework (Django or Pyramid) for the web interface.

The package selection will be interactive, searching through apt api to help user finding them. This method will provide clean images for use in a cloud on a virtualization host (ssh host key unique per image, user password choice).

The student will learn Debian python APIs, chroot and deboostrap usage. He will also learn web development and how to generate custom virtual images.