Differences between revisions 65 and 66
Revision 65 as of 2012-03-21 21:25:59
Size: 32439
Comment: add d-i netcfg project
Revision 66 as of 2012-03-21 21:29:31
Size: 32543
Comment:
Deletions are marked like this. Additions are marked like this.
Line 373: Line 373:
  * Improvements to debian-installer in other areas. For example the partitioner also needs some work.

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

  • Description of the project: At least 8-10 lines describing what the project is about; it is really important to have a good description if you want to attract students who are interested by the idea. This does not need to be a very technical description, but something that stirs interest and is complete enough to allow a student to judge whether s/he wants to work on the particular project or not. It does not need to be a complete road map either and does not need to explain all the tiny details and whatnot -- the mentor can tell that to interested students, or they can work out the exact details together.

  • Confirmed Mentor: Name of the mentor

  • How to contact the mentor: (mail, IRC, etc)

  • Confirmed co-mentors: It is not compulsory to have co-mentors, but it is a good idea. Secondary mentors do not need to be as knowledgeable as the first one in the project, but they should be available to help the student if s/he is stuck and the main mentor is busy / not available.

  • Deliverables of the project:

  • Desirable skills: Skills that the student has or is willing to develop. Remember, the students do not have as much experience as the mentor.

  • What the student will learn: At least 2-3 lines telling the students the skills they develop and how they will improve Debian. Do not focus on the technologies rather use something that could motivate the prospective student to take your project.


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

  • Confirmed Mentor: Sylvestre Ledru

  • Confirmed co-mentor: Paul Tagliamonte

  • How to contact the mentor: sylvestre@debian.org

  • Deliverables of the project:

    • Build services modified to be able to use clang instead of gcc/g++
    • Integration into the Debian infrastructure (buildd.d.o, and similar services)
    • An easy way to switch of compiler between gcc/g++ and clang
    • A way to build a package with a different compiler (gcc, clang, intel compiler, etc)
    • Time permitting, a fully clang-built Debian installation
  • Desirable skills:

    • A reasonable knowledge of Debian packaging, or willingness to learn it fast.
    • Familiarity with chroots
    • An interest in build tools and infrastructure
  • What the student will learn:

    • The student will learn how to use clang, and how to make use of the features it provides over gcc/g++
    • The student will learn more about the Debian build-related infrastructure and software, such as sbuild, wanna-build and the buildds.
    • As a consequence of the above, the student will also learn about the subtle bugs that crop up when using a different compiler, and ways to debug or otherwise handle them.
  • Requirement:

    • The mentors require the student to update the output of clang --version (add his name for example) and send the patch to the mentors. Fix of a few Debian bugs (in any package) will be strongly appreciated.

  • Sample of a potential outcome


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.

  • Confirmed Mentor: Sylvestre Ledru

  • How to contact the mentor: sylvestre@debian.org

  • Deliverables of the project:

    • libc++ packages
    • A quick and easy switch from libstdc++ to libc++ (update-alternatives ?)
  • Desirable skills:

    • A reasonable knowledge of Debian packaging, or willingness to learn it fast.
    • Familiarity with chroots
    • Libraries management
    • Courage!
  • Requirement:

    • The mentors require the student to update the output of clang --version (add his name for example) and send the patch to the mentors. Fix of a few Debian bugs (in any package) will be strongly appreciated.

  • What the student will learn:

    • The student will learn how to use LLVM build
    • The student will learn more about the Debian packaging and its internal.


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:

  • Develop a web interface that presents this information in a clear and accessible way.
  • Write an API to access this information.

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.

  • Confirmed Mentor: Sukhbir Singh [sukhbir.in@gmail.com]

  • Confirmed co-mentor: Andreas Tille [tille@debian.org]

  • How to contact the mentor: teammetrics-discuss public mailing list. IRC: SukhE [available between 21:00-01:00 GMT +5:30]. The mailing list is preferred, however if you want to discuss your idea in private, use email or IRC.

  • Deliverables of the project:

    • Development of an interface to the Team Metrics project.

    • Writing tools to verify that the information gathered using the metrics is correct.
  • Desirable skills:

    • Experience with Django or Pylons (and Python of course!) and web development in general. We prefer Django/ Pylons because it will be easier for us to maintain the code, but if you feel otherwise, convince us and we might agree.
    • Familiarity with Git.
  • What the student will learn:

    • The student will learn to implement a complete web front-end to a project with real-world data, exploiting development with Django/ Pylons and UI/UX techniques.
    • The student will also learn practical development methodologies by contributing to an existing code base and working in a team by communicating with the mentors and the Debian community.
  • Sample of a potential outcome:

    • If this project is implemented, by the end of the summer, the Team Metrics project should have a proper web interface to easily access the information and then the Debian community can use this to see how a team is performing.


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.

  • Confirmed Mentor: Niels Thykier

  • How to contact the mentor: mail: niels@thykier.net, IRC nick: nthykier

  • Deliverables of the project:

    • New automated harness test-suite
    • New harness frontend to generate static html reports.
    • User manual for the new frontend
  • Desirable skills:

    • Perl
    • Black box testing, or willingness to learn it

    • Ability to write documentation (docbook and POD knowledge is great, but can be learned along the way)
    • Familiarity with any templating language (Text::Template, or Template::Toolkit, or something else)
  • What the student will learn:

    • You will learn methods to reduce the workload when dealing with massive data sets (via incremental runs), while working on a tool that is run on the whole Debian archive and is a key piece of our QA toolset. You will be able to learn how to do black box testing on "non-trivial" black boxes. Along the way, there's a possibility to learn a lot about Perl, the POD and docbook documentation formats, gnuplot, make and shell.


Semantic Package Review Interface for mentors.debian.net

  • About 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.

  • Description of the project:

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.

  • Confirmed Mentor: Nicolas Dandrimont

  • How to contact the mentor: nicolas.dandrimont@crans.org, IRC olasd on #debexpo (on irc.debian.org also known as OFTC)

  • Confirmed co-mentors: Arno Töll, debian@toell.net, IRC daemonkeeper; Stuart Prescott, stuart+debian@nanonanonano.net, IRC themill

  • Deliverables of the project:

    • A versatile storage backend for packages and associated metadata in debexpo
    • A nicer web query interface for the package metadata, based on the new storage backend
    • A richer metadata set on source and binary packages, to ease the finding of prospective sponsors
  • Desirable Skills:

    • Python (Debexpo is based on the Pylons framework and uses sqlalchemy as ORM; prior knowledge of these frameworks or the underlying modules is appreciated but not by any means mandatory)

    • Basic git knowledge (Currently used for Debexpo development, and could be used for the package storage backend)

    • Basic understanding of Debian packages (can be acquired easily, too)
    • Some HTML/CSS knowledge (this is a web development project after all...)
  • What the student will learn:

    • How Debian source packages work and how to avoid common pitfalls in packaging
    • All about the Debian Mentors package review process, as used by Developers
    • Debian QA tools (Package Tracking System, Lintian, Debtags, ...)
    • How to interact with the Debian infrastructure (mailing-lists, bug tracking system)
    • How Debian teams work, what they do, community work in Debian.


Package an OpenStack use case

  • Debian GNU/Linux could become a leader in the cloud. The http://openstack.org/ cloud software suite is state of the art and Free Software. The first stable OpenStack release published in April 2012 is made of many parts: it is a challenge to package. A team was organized in 2011 to initiate the packaging work : https://alioth.debian.org/projects/openstack/ . However, it will take more than a few motivated individuals to meet the expectations of the system administrators using Debian GNU/Linux. You could be part of this unique opportunity to shape the future of cloud computing. The members of the OpenStack packaging team are experienced system administrators from Europe, North America and Asia : literally working 24/24 ;-) They invite you to join them to polish an easy to install set of packages so that anyone can deploy and use a cloud infrastructure within hours.

  • Confirmed Mentor: Loïc Dachary

  • How to contact the mentor: loicd on irc.oftc.net#debian-openstack

  • Confirmed co-mentors: Ghe Rivero and Thomas Goirand

  • Deliverables of the project:

    • OpenStack packages implementing the use case proposed by the student in his application. Debian GNU/Linux should address all imaginable use cases, but it should do so in a simple and straightforward maner.

    • An example use case is : I have two machines. I install OpenStack packages and answer a few interactive questions. I run a VM. I login to the VM.

    • The student would first document the use case into a HOWTO with manual steps. Example for the above use case : http://wiki.debian.org/OpenStackHowto?action=recall&rev=10

    • After this intermediate deliverable is approved by the mentor, the student will proceed by implementing the use case so that the HOWTO is no longer necessary. In other words he translates the HOWTO into a proper set of Debian packages or modifies the existing Debian packages
    • The deliverables will be tested by a continuous integration tool. and checked for clear documentation and robustness.
  • Desirable skills: Debian packaging, python development, system administration, networking. In order to prepare a good submission, it is worth trying to install OpenStack (a HOWTO can be found at http://wiki.debian.org/OpenStackHowto ), play with it and think about a use case.

  • What the student will learn: Debian GNU/Linux packaging techniques involving the most advanced system administration topics. Operate a cloud single from top to bottom using state of the art software. Contribute to one of the largest Free Software community.


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.

  • Confirmed Mentor: Hector Oron

  • How to contact the mentor: zumbi@debian.org IRC #emdebian on OFTC

  • Confirmed co-mentors: Marcin Juszkiewicz, marcin.juszkiewicz@linaro.org

  • Deliverables of the project:

    • Cross-toolchain packages using cross-arch dependencies, building against multiarched libraries, and defaulting to doing cross-builds using multiarch paths.
    • Tools changes to support this in the archive
  • Desirable skills:

    • Knowledge of Debian packaging, toolchain building, or cross-building would make it quicker/easier to get up to speed.
    • Multiarch knowledge

    • Knowing a bit of make, bash and perl might help to get up to speed.
    • You need to be persistent and capable of learning about tools and builds - you do not need to be a great coder. This project is fundamentally very simple, but the details matter and there are a lot of them.
  • What the student will learn: You will learn how cross-toolchains are built in a distribution, how packaging works, and how amazingly cool multiarch is. You will also learn much more than you ever wanted about the sordid details of compiler build paths, but that's more fun than it sounds, honest :-) Finally you will learn about the tools, processes and people behind the scenes that make a distro like Debian happen.


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

  • Confirmed Mentor: Wookey

  • How to contact the mentor: <wookey@debian.org> IRC #emdebian on OFTC

  • * Confirmed co-mentors: Pietro Abate, <Pietro.Abate@pps.jussieu.fr>

  • Deliverables of the project:

    • Tool to order builds for bootstrapping a new architecture
  • Desirable skills:

    • Understanding of debian port bootstrapping process
    • Programming ability - language not important, but existing relevant tools are in ocaml, python and perl.
    • Some graph theory understanding
  • What the student will learn:

    • How to bootstrap Debian, and an excellent understanding of build-dependencies, cross-build dependencies and the tools to analyse them
    • How to define, break down, and solve a thorny problem* Description of the project:

    • How to write a small tool which is an interface to other tools, doing just one job and doing it well.


SysV-init file creator from systemd service files

  • Description of the project:

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:

  • No-one wants a flag day;
  • Non-Linux architectures are not currently supported by any of the successors of SysV init (and such support is not probable to happen in the foreseeable future);
  • Imposing the maintainance of multiple init descriptions (say: one SysV init script and one systemd service file) on maintainers will be error-prone, especially on low-usage init systems.

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.

  • Confirmed Mentor: ?TollefFogHeen

  • How to contact the mentor: IRC: Mithrandir or email: tfheen@debian.org

  • Confirmed co-mentors: DidierRaboud (OdyX@debian.org)

  • Deliverables of the project:

    • a tool that, given a systemd service file will output the corresponding init script implementing the corresponding commands/settings;
    • a document or policy describing the limitations of the init scripts and service files;
    • a huge reduction in code duplication currently happening in the SysV init scripts;
  • Desirable skills:

    • Experience in handling (SysV) init scripts (writing them, patching them, ideally maintaining some)
    • Knowledge of any language available in a standard Debian base system, suitable for writing such a conversion tool (typically an interpreted language, such as perl or python; the choice is up to the student).
  • What the student will learn:

    • Internals of the Debian boot process and the various init systems (both old SysV and modern systemd);
    • How to write code portable across all architectures and kernels supported by Debian;


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).

  • Confirmed Mentor: Michael Vogt mvo@debian.org (irc: mvo) [GMT + 1]

  • How to contact the mentors: irc, public mailinglist

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

  • Deliverables of the project:

    • config based registration of content for simple cases
    • text-protocol similar to acquire-methods for complex(er) cases
    • Plugins to download Packages, Sources and Translation files
    • a (public) parser for the sources.list that is exported from libapt
    • allow plugins to be configured/disabled for each source in sources.list
    • improvements to the acquire logic
    • propose plugins for apt-file, debtags, …
  • Desirable skills:

    • C++
  • What the student will learn: You will learn how to refactor a complex codebase, about plugin mechanisms that use IPC, writing/extending parsers, security (hashsum checking, gpg authentication, avoiding man-in-the-middle attacks). And how important careful work is on a tool that is used by millions of people (literately!).


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.

  • Confirmed Mentor: Wookey

  • How to contact the mentor: wookey@wookware.org or IRC #emdebian, #multiarch on OFTC

  • Confirmed co-mentors: Jonathan Austin <Jonathan.Austin@arm.com>

  • Deliverables of the project:

    • Set of patches for control and rules files to provide staged 'bootstrap' builds that break cyclic build-deps
    • Multiarch cross-building patches that allow cross-building of the initial core set of packages
  • Desirable skills:

    • Knowledge of packaging and package-building
    • Knowledge of cross-building methods and issues
  • What the student will learn: How Debian is bootstrapped, dependencies fit together, and how multiarch cross-building works. You will learn what is core and what is optional in a range of pieces of software, as well as getting great insight into the myriad forms of packaging of different tools, languages and libraries. You will understand what a core GNU/linux system is actually made from, the whole set of package and build tools, what _really_ happens when you build a bit of software, and the coolness of the multiarch mechanism.


Improve debian-installer network setup

  • Description of the project: The debian-installer already provides a component to configure the network during installation. But this component lacks several important features. The goal of the project is to integrate new functionality while keeping things simple and easy for the most common cases. Possible new features:

    • Improve wireless setup
      • show available SSIDs
      • support other encryption and authentication methods than WEP and WPA-PSK
    • IPv6 support (patches available, but probably needs some work)
    • work on some of the (wishlist) bugs on the netcfg bug page

    • improve the user interface
    • Improvements to debian-installer in other areas. For example the partitioner also needs some work.
  • Confirmed Mentor: Gaudenz Steinlin

  • How to contact the mentor: gaudenz(at)debian.org

  • Confirmed co-mentors: none yet, but I'd like to have at least one co-mentor

  • Deliverables of the project:

    • patches for the netcfg installer component
    • patches for other related debian packages
    • experimental installer builds available for wider testing of the new functionality
  • Desirable skills:

    • Basic knowledge of Debian packaging (or motivated to learn about this)
    • Familiarity with the debian-installer as a user (or motivated to dig into the intstaller internals)
    • Basic C and shell coding (Installer components are either written in C or Shell, so this is a must)
  • What the student will learn:

    • How the Debian installation system works
    • How it's built from a very flexible set of different small components
    • Working in a very constrained and simple environment. The debian-installer runtime environment has none of the usual high level scripting languages available and must run on very diverse systems ranging from small embedded boards to high end servers.