The main page is at SummerOfCode2013.

Project template

All the project descriptions should follow the following template.

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.

Projects with confirmed mentors

Please keep this section clear of project ideas without confirmed mentors, to avoid any confusion for prospective students. Such projects should be published in the next section.

Test suite for Debian's archive management software (dak)

• Description of the project:

  • The software managing Debian's archive (ftp.debian.org) currently has no test suite. This means there is no automated way to check that changes don't introduce regressions. Large parts of dak are dependent on the current state of the archive, so simple unit tests will not help in many cases. The goal of this project is to develop a framework for running tests and implementing such tests. To make sure tests are repeatable, they should be run in a clean installation. So automatically setting up an installation might also be a required part of the project.

    See http://lists.alioth.debian.org/pipermail/soc-coordination/2013-March/001408.html for a bit more detailed description.

• Confirmed Mentor: Ansgar Burchardt

• How to contact the mentor:

  • mail: ansgar@debian.org, IRC: ansgar on OFTC and freenode

  • mailing list: debian-dak@lists.debian.org (http://lists.debian.org/debian-dak), IRC: #debian-ftp on OFTC

• Confirmed co-mentors: Jörg Jaspert

• Deliverables of the project: Infrastructure to develop and run tests for dak and some such tests.

• Desirable skills: Python, PostgreSQL, creating Debian package (just basics).

• What the student will learn: Besides planning and developing a test suite, students will get a view into the infrastructure running Debian's archive.

ZFS on Linux integration

• Description of the project: ZFS provides many more advanced features than any other filesystems available to Linux users, and it's proven in production environment for years. There is btrfs under heavy development to provide similar functions, while the way is still quite long to go. At the same time native ZFS on Linux (ZoL) is a low hanging fruit for Linux users. To achieve this target we have two things to do: make zfs actually work on a Linux distribution; make it better integrated into the system, pushing its higher-level functions more handy to end users. This project covers the both parts, which is to provide a functional ZFS support in Debian by integrating basic functions into the system and more in-depth integration. Many of the outcomes of this project would be reusable to btrfs with minimal changes.

• Confirmed Mentor: LiangGuo

• Confirmed co-mentors: CarlosLopez (clopez@igalia.com; clopez on IRC)

• How to contact the mentor: mail: pkg-zfsonlinux@lists.alioth.debian.org

• Deliverables of the project:

  1. Integrated ZFS on Linux support via "apt-get install" and support for ZFS root filesystem.
  2. Write or improve wrappers including zfs-auto-snapshot, apt-zfs-snapshot, and maybe more.
  3. Improve debian-installer/partman integration. This involves creating volumes when doing the initial installation, and maybe separate system directories (/boot, /usr, /lib, etc) from user directories (e.g. /home).

  4. A beadm-like tool. beadm is a wrapper available on Solaris, and it is dependent to previous item like the initial filesystem layout created by the installer. Changes to debian-installer/partman and grub2 would be required.

  5. Optionally a testing tool to verify if the integration works with common setups, i.e. automation testing using virtual machines to simulate common setups and usages (desktops, servers, storage servers, etc).

• Caveats

  1. Debian installer currently does not include out of tree kernel modules, so in short-term it would not be possible to include ZoL in official debian-installer images. Adding this point, this project needs to create a third party d-i image as part of its deliverable.

• Desirable skills:

  1. Familiar with Debian packaging.
  2. Knowledge about Debian system, especially debian-installer, grub2, dkms, and the Linux kernel.
  3. Knowledge of common storage systems (RAID, HBA, iSCSI, NFS, Samba, etc)
  4. Experience of using ZFS on BSDs and Solaris.

• What the student will learn: experience of filesystem integration and collaboration with different teams

• Additional notes : Since debian-installer has policy to not include out-of-tree kernel modules, please tell what would be a possible long-term solution to handle ZoL module in debian-installer for official images in your application.

OpenRC init system in Debian

• Description of the project: WARNING: a lot of hacking fun is included in this project! We all agree in Debian that sysv-rc is old, clumsy, needs verbose init.d scripts, and needs to be replaced by something modern. Though we don't agree on what we should be using as a replacement. One of the contenders for sysv-rc replacement is OpenRC, which reimplement /etc/init.d/rc (but not /sbin/init, which doesn't have to go). There is already a Debian package for OpenRC available from git://anonscm.debian.org/collab-maint/openrc.git. Even if that package can be installed, the work on it is only the beginning of a much longer integration work. The student for this GSoC project will have to do all what is needed so that OpenRC integrates well into Debian, and upgrades correctly from sysv-rc, all this in a Debian policy compliant way. This project should also include mechanisms to convert and/or use existing init.d scripts which are currently using the LSB headers (which OpenRC doesn't understand yet at this point), so that the Debian project will not have to rewrite absolutely all init.d scripts. Ideally, OpenRC should become a drop-in replacement for sysv-rc that "just works" (tm) without having to work on any other package than OpenRC itself, if that is possible (and at this point, I believe it is possible).

• Confirmed Mentor: zigo

• How to contact the mentor: mail: zigo@debian.org, zigo on many IRC channel on the OFTC network. Note that direct communication with someone in the west coast US will be hard because of timezone issues, so I would prefer someone living between GMT-2 and GMT+10 (so, Europe or Asia would do), so that we can chat on IRC.

• Confirmed co-mentors:: Roger Leigh <rleigh@debian.org>

• Confirmed co-mentors: Benda Xu <heroxbdATgentooDOTorg>

• Deliverables of the project: A working OpenRC package, including OpenRC scripts which comes with it, and also for basic daemons commonly used (like for example: sshd, acpid, crond, etc.) so that OpenRC can be used to replace sysv-rc, including a system to convert existing init.d scripts.

• Desirable skills: A good overall general knowledge about Unix is mandatory. Understanding about how the boot process works would be an asset, but isn't mandatory (it can be learn quickly). Good scripting skills are also absolutely necessary. C language skills would be a plus since a (small) part of OpenRC is written in this language.

• What the student will learn: A lot of Unix magic will be learn by the student picking-up this (I believe fun) project. Lots of Debian internals and packaging (update-rc.d, dpkg, start-stop-daemon, etc.) can be learn as well if the student don't know these tools yet.

• Additional note to applicants: When writing for applying to the project, please tell what your plan is to add LSB init script compatibility to OpenRC, since that is the most important part of the project. Please Cc: Benda when writing a mail to me (eg: zigo). Also note that we gather information here: http://wiki.debian.org/OpenRC (which you can feel free to edit if you have something to add there...). There is also http://www.gentoo.org/proj/en/base/openrc/ and http://lwn.net/Articles/512719/ Please don't ask for more technical details about the project, as there's nothing much more than what is available there, in fact part of your work is to find out what we need to do.

Enabling free multimedia real-time communications (RTC) with Debian

• Description of the project: Debian contains various applications for RTC, including softphones, SIP proxies, XMPP/Jabber servers and full soft PBXes such as Asterisk. Unfortunately, users continue to report problems getting them to all work together. A typical complaint is that user A can only call user B if using the same softphone, same version, and on the same LAN. Modern IETF standards such as ICE/STUN/TURN are supposed to enable successful calling across NAT/firewalls, much like with proprietary softphones. Debian has the foundations for this (see packages reTurn and sid/turnserver) but more work is needed to make a turn-key solution based on Debian that is convenient for mass deployment. The project could involve some combination of the following activities, based on the interests and capabilities of the student:

  • setting the benchmark for Debian 8.0: defining the RTC experience that Debian should promise to the Debian community (e.g. what level of convenience and interoperability guarantees should we offer for Debian 8.0 and beyond),
  • looking at the role of next-generation solutions, e.g. WebRTC and mobile VoIP
  • measuring the capabilities of existing and potential packages against the benchmark,

  • setting up continuous integration or test environments to provide ongoing, automated interoperability testing for key packages within the testing and unstable environments

  • identifying and implementing any quick wins: e.g. packages that only need minor patches or configuration changes to enjoy significant improvement

  • identifying at least one more detailed project: a new package or significant improvement to an existing package that will bring significant benefit (e.g. packaging of Jitsi, SylkServer conferencing, FreeSWITCH or Linphone)

• Confirmed Mentor: Daniel Pocock

  • https://lists.fsfe.org/mailman/listinfo/free-rtc

• Confirmed co-mentors: (volunteers needed)

  • Sylvain Berfini

  • JesusPerez (jesus.perez@quobis.com; jesusprubio on IRC)

• Deliverables of the project: contribution to a strategic roadmap for RTC in Debian. Improvement or addition of at least one package in such a way as to help fulfill the strategy.

• Desirable skills: any one or more of the following: C, C++, Java, SIP, XMPP, JavaScript/HTML5/WebRTC, Android

• What the student will learn: the student is likely to become an expert in developing fields like WebRTC and is likely to end up knowing more about these fields than many existing developers.

One-time-password (token) based authentication and transactions

• Description of the project: Debian now has various packages such as wheezy/oathtool and wheezy/dynalogin-server to support token authentication for various use cases. The basic use cases are UNIX logins (using wheezy/libpam-oath or experimental/libpam-dynalogin and OpenID (web based) login using wheezy/simpleid-store-dynalogin. The student will look at adding more depth in this area, here are some possible examples:

  • developing support for Challenge-Response authentication ( CROTP ) in oath-toolkit

  • developing an asynchronous AMQP-based interface for wheezy/dynalogin-server

  • enhancing wheezy/simpleid to create user profiles on the fly

  • using some combination of these technologies to enable a more secure experience with digital currency transactions (e.g. for Bitcoin)

• Confirmed Mentors:

  • Daniel Pocock

  • Simon Josefsson

  • Luke Faraone

• How to contact the mentors:

  • http://lists.alioth.debian.org/mailman/listinfo/pkg-auth-maintainers

• Confirmed co-mentors: potentially other members of the pkg-auth team

• Deliverables of the project: to be identified in consultation with the mentor(s)

• Desirable skills: C, C++, Java, PHP, cryptography

• What the student will learn: becoming experienced in UNIX security, distributed authentication systems for the web and potentially even systems for authorisation of electronic payments

PTS rewrite in Django

• Description of the project: the Package Tracking System (PTS) is the main, source package-centric portal for Quality Assurance and package monitoring in Debian. It is widely used and in good shape. However, the technology it has been built upon is starting to show its age; also, the PTS currently uses a wide range of technologies (Python, Perl, shell script, XML, XSLT, ...) making it more hard to hack on than needed, in particular if you consider which technologies are nowadays popular in the Debian community. Finally, the current design of the PTS is entirely static, with refreshes occurring 4 times a day. That is good for performance, but it is a blocker for making the PTS a "live" data monitor and makes it unnecessarily hard to scale up to more frequent data updates. The content is also very Debian-specific and makes it unnecessarily difficult to setup a PTS instance for a Debian derivative for example. A more modular approach should be possible. This project aims at providing a new, alternative implementation of the PTS, using technologies that are popular in Debian (Python + Django), and getting rid of blockers for future evolution of the PTS, most notably the ability to provide live updates and to customize the content by enabling/disabling modules.

• Confirmed Mentor: Raphael Hertzog (PTS original author and long-time maintainer)

• How to contact the mentor: RaphaelHertzog / hertzog@debian.org / buxy on IRC

• Confirmed co-mentors: StefanoZacchiroli

• Deliverables of the project:

  • drop-in PTS replacement written in Python using the Django web framework. It should be possible to run the new implementation locally, obtaining pages (and features, most notably: mail subscriptions) equivalent to the current ones.
  • Time permitting, some scalability assessment might be desirable. It's to be expected that parts of the dynamic content should be cached (using Django's cache feature) to provide a good compromise between freshness and performance.

• Desirable skills:

  • experience in Python+Django development
  • familiarity with the PTS current implementation

• What the student will learn: developing a large and popular dynamic web application; migrating an existing and in production code base to an alternative implementation; (time permitting) doing performance assessments of static vs dynamic websites

• How to candidate:

  • Check out the PTS wiki page, grab its source code from the subversion repository, get familiar with the codebase.

  • Prepare a patch adds a bullet with your name under the "todo" section of each package page. Include this patch as part of your application on google's melange service.

  • Join #debian-qa on irc.debian.org or debian-qa@lists.debian.org (subscribe here: http://lists.debian.org/debian-qa/) and get to know the people in the QA team.

  • To showcase your Python skills, try to rewrite bin/dispatch.pl as Python script and include it in your application on google's melange service.

    • The script is relatively simple, it takes an email as input, it categorizes it based on multiple criteria, it looks up in a DB who is interested by this category of mail on this package and then it forwards the mails (adding some VERP tracing for a custom bounce handler).
    • I don't want to give too much cues on how this should be reimplemented but for the DB part you should use Django's ORM so you have to create a small models.py.
    • The script is in Perl and has been written years ago, it's probably not a good idea to rewrite it word-for-word. The resulting design or architecture will be a big factor to help us decide who will get the project (that said, don't overdo it!). The testability of the resulting code is also something important. If you have further questions, just ask!

  • Fill in your SummerOfCode2013/StudentApplications with a list of expected tasks and a rough schedule. Then submit your application to google's melange service with a link to the wiki page and with your patches and the rewritten bin/dispatch.pl.

OpenJDK and Debian

• Description of the project: The goal of this project is double. The first step would be to finalise the transition to the OpenJDK 7. This means:

  • Managing with the mentor a full rebuild of the Debian archive on the Amazon cloud with the OpenJDK

  • Report bugs on the failing packages (Please note the existing openjdk7-transition tag)

  • Fix them and propose patches (note that many of them have been fixed in Ubuntu)

  • Update default-jdk & default-jre to point to OpenJDK 7

  The second step will be to package the OpenJDK 8, perform the same tasks and report potential upstream issues to OpenJDK.

• Confirmed Mentor: Sylvestre Ledru

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

• Confirmed co-mentors: Welcome

• Deliverables of the project: Jessie based on the OpenJDK 7, a proof of concept for OpenJDK 8

• Desirable skills: Debian / Ubuntu packaging experience

• What the student will learn: The OpenJDK packaging, Java packaging, interacting with the Debian community, etc

• Expected from the student: Please provide a patch fixing a build failure of a Java package built with the OpenJDK 7

scan-build on the Debian archive

• Description of the project: scan-build is a program provided in the clang package. It provides an excellent static analyzer for C, C++ and Objective-C code. It can find bugs that a compiler cannot find, providing a visual report. Example: http://scan-build.scilab.org/. The goal of the project is to rebuild the whole Debian archive using scan-build, extracting the report and publishing them on a common interface (daca?). One of the step of this GSoC will to make this process fully automatic using the buildd infrastructure. See the thread on the daca mailing list on this subject.

• Confirmed Mentor: Sylvestre Ledru

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

• Deliverables of the project: A website with reports of all Debian packages with scan-build errors

• Desirable skills: Debian / Ubuntu packaging experience, pbuilder

• What the student will learn: Compilation procedure, static analysis

• Expected from the student: A scan-build report of a Debian package with the procedure to perform it

Debian metrics portal

• Description of the project: To improve, one needs to measure, apply changes, and see how the changes affect the observed quality. In Debian, we have a lot of project-wide metrics, Statistics, and graphs. Unfortunately they are scattered and maintained in a non-coordinated manner, resulting in recurrent shortages, and the lack of a uniform interface to view, add, and query Debian metrics. This project aims at building a Debian metrics portal with a uniform (Web) interface to peruse Debian metrics, as well as a uniform (programming) interface to maintain them.

• Confirmed Mentor: StefanoZacchiroli

• How to contact the mentor: see mentor wiki page

• Confirmed co-mentors: none yet

• Deliverables of the project:

  • standardized interface to add/remove metrics to be graphed (possibly with different sampling rate)
  • integration of existing graphs in the metrics infrastructure
  • web interface to show daily (or more frequently) updated graphs of the various metrics
  • dynamic web interface to graph, on demand, specific metrics (possibly more than one at a time) over specific time periods
  • (optional) package the developed code to ease deployment on Debian-based machines

• Desirable skills:

  • Python programming

  • Python libraries: some Python templating engine (e.g. genshi, jinjia2, etc.) for the static part; Django for the dynamic part

  • knowledge of matplotlib for the graph generation part

  • please include as part of your application a Python program that uses matplotlib to graph some of the metrics from UDD history table

• What the student will learn: deal with live legacy data and code; consolidate into a single, well-designed architecture existing functionalities; this will help Debian in monitoring its strength and deficiencies, and evaluate the usefulness of changes to project processes

Leiningen & Clojure packaging

• Description of the project: Leiningen is a Clojure project automation tool, used by the vast majority of Clojure projects. If we want to have Clojure libraries and applications packaged for Debian, we need Leiningen too. However, packaging Leiningen is far from a trivial tasks: all the dependencies need to be packaged too, for one. And it becomes useful only when packages that need Leiningen will become easier to package aswell. Therefore, the goal of this project is two-fold: package Leiningen and its dependencies, and write tools (like dh_lein2) that will either fully automate parts of the Clojure packaging process, or at worst, make it considerably easier to do so. This is a required step to have a usable Clojure ecosystem within Debian.

• Advocate: Gergely Nagy

• Confirmed Mentor: Wolodja Wentland (debian@babilen5.org; babilen on IRC), Gergely Nagy (algernon@debian.org; algernon on IRC)

• How to contact the mentor: You can mail pkg-clojure-maintainers@lists.alioth.debian.org or pop into #debian-clojure on irc.oftc.net

• Confirmed co-mentors: Paul Tagliamonte (paultag@debian.org; paultag on IRC); Phil Hagelberg (phil@hagelb.org; technomancy on IRC)

• Deliverables of the project:

  • Leiningen2 and dependencies packaged for Debian
  • A tool that helps packaging Clojure projects that depend on Leiningen easier (along the lines of dh-make)
  • A tool that helps building and assembling the debianised package (dh_lein2)
  • Documentation about the tricky bits of Clojure packaging, common pitfalls, and things to pay extra attention to.

• Desirable skills:

  • Reasonable knowledge of the Clojure language, tools and ecosystem
  • Familiarity with Java, maven in particular is highly recommended
  • Basic knowledge of Debian packaging (if you know what debhelper is, you're good)

• What the student will learn:

  • A lot about Debian packaging, and about writing tools to aid packaging
  • The dark corners of the Clojure and Java ecosystems
  • The difference between the Clojure/Java and Debian packaging philosophies

• Pre-Application Contribution This year we require students to make a small contribution to the project they are interested in. Doing this not only allows us to get an impression of the way in which the student works and interacts with the mentors, but also allows the student to get an impression of the work that lies ahead. The task consists of creating a prototype implementation of a dh_lein2 helper that does nothing else, but to print the message '(println "Somebody set us up the Leiningen")' during the package build. The helper should be activated by "dh $@ --with dh_lein2" in debian/rules and can be implemented in whatever way the student deems appropriate. Students are encouraged to investigate how javahelper is integrated with debhelper before implementing their own solution.

MIPS N32/N64 ABI port

• Description of the Project: MIPS is one of the most elegant RISC CPUs in the industry, and there are quite a lot different usages in its family. This project attempts to create a new MIPS N32/N64 ABI port for Debian. Different from O32 (used by existing mips/mipsel port), N32 is an address model that has most 64-bit capabilities but uses 32-bit data structures to save space and process time, it is quite similar to the ongoing x32 port for x86 platform. At the same time, N64 is a full 64-bit address model which is comparable to x86_64 on x86. There is consensus that N32/N64 ABI would give capable devices better performance, while O32 ABI should be kept for devices that is only 32-bit capable. Since Multiarch support is almost available in Debian, we are able to apply the state-of-art technology to help us on both bootstrapping and future usages. Users can run N64 kernel with mixed N32/N64 userland to take advantage of both the performance and the large memory as needed.

• Advocate: AnthonyFok

• Confirmed Mentor: YunQiangSu

• Confirmed co-mentors: ZhangLe (r0bertz AT gentoo.org), DavidDaney (david.daney AT caviumnetworks.com), YanHua (yanh AT lemote.com)

• How to contact the mentor: mail: debian-mips@lists.debian.org

• Deliverables of the Project:

  1. Cross toolchains on at least amd64 for mips64 and mips64el systems.

  2. Running sbuild instances with mips64 and mips64el chroots (build-essential), resolve outstanding porting issues getting in the way of satisfying build-essential.

  3. Do a try build of the archive, attempting to meet the requirement of uploading to debian-ports.org. This could be limited by the performance of available developer box thus not required to cover 100%.
  4. A performance comparison of O32, N32 and N64 ABIs.
  5. It is also desirable to have similar setups for mipsn32 -el and non-el variants.

• Desirable Skills:

  1. Familiar with base system environments.
  2. Some knowledge of C/C++ and debugging.
  3. Good understanding to what is Multiarch and how it works.

• What the Student Will Learn: Experience of bootstrapping on a new architecture port from scratch.

• References: mips64/mips64el n32 port discussion bootstrap docs.

• Additional notes : When writing for applying to the project, please tell us your plan on how to do the comparison of performance among different ABIs? Also please give a simple example on doing the mesurement for the i386 and x32 architectures, or amd64 and x32 architectures.

A cloud image for bioinformatics with Debian

• Description of the project: This is a call for bottom-up proposals structured by students themselves along the following lines. 2012 has been a year of progresses in Debian's support for clouds. Combined with Debian's leadership in the distribution of packaged scientific and medical software, this opens opportunities for establishing Debian as a first-class provider of virtualised solutions for bioinformatics. To be successful, proposals will need to go beyond simply booting a Wheezy image and typing apt-get install med-cloud, and take into account the prior art of Cloud Bio-Linux, which is already distributing our packages in cloud images. They will have to address other problems, such as the need for precise versions of software, the need for images that will happily crunch hundreds of gigabytes of data, the need for parallelisation of workflows, etc. The project's deliverable must be useable on Free platforms, and the proposal needs to explain which infrastructure will be used during the development.

• Potential mentor: CharlesPlessy, other mentors welcome.

• How to contact the mentor: mail: debian-med@lists.debian.org or debian-cloud@lists.debian.org

• Deliverables of the project: Bioinformatics with Debian on the Cloud

• Desirable skills: Familiarity with virtualisation, cloud environments, or scientific computing are a good start.

• What the student will learn: Depending on the contents of the proposal, the student will learn about the Debian system and its installation, about the Debian Blends, and about the Debian infrastructure.

Redesign metapackage creation for Debian Blends

• Description of the project: In Debian Blends a basic way to install packages belonging to a certain user task is a set of so called metapackages. These metapackages are created by using so called tasks files as data input specifying dependencies from binary packages. The package blends-dev contains tools to create a Debian source package which has set all dependencies according to the specification inside the tasks file which are validated against the packages inside the package pool. This ensures that the resulting metapackages will install nicely into a system that is up to date at the time of creation of this source package. Currently blends-dev is verifying the package pool of the architecture on that the source package is created (when blends-dev is called). In practice this has the effect that the most popular architectures (i386, amd64) are used as reference for metapackages which are intended to work on all available Debian architectures. Strictly speaking this is wrong even if there is no known case were this has leaded to practical problem. An additional source of information to create metapackages could be to use the information of Debtags. Currently the maintenance of Debtags and tasks files is independent from each other but this does not necessarily need be the case. There could be ways to either synchronise the information or at least regard both sources of information into account when creating metapackages. The task of the GSoC project is to rewrite the blends-dev code to enable architecture dependent metapackages.

• Hint for solving this task: It seems to be the best way to use the UltimateDebianDatabase (UDD) to obtain the relevant information. The UDD is a commonly used resource in Blends (see other GSoC project) and provides a very handy access to the necessary information about binary packages. Because the implementation is very different than the current code the task is basically programming from scratch and thus the prefered programming language for this task would be Python (the current code is in Perl for historic reasons).

• Confirmed mentor: AndreasTille

• How to contact the mentor: mail: debian-blends@lists.debian.org

• Deliverables of the project: Procedure to create Blends metapackages for all supported architectures

• Desirable skills: SQL, Python

• What the student will learn:

  • learn structure of UltimateDebianDatabase

  • learn usage of Debtags

  • become comfortable with the idea of DebianBlends

Enhancing Debian Blends web sentinel

• Description of the project: A very important feature of Debian Blends is the so called web sentinel currently featuring so called tasks (example) and bugs (example) pages. It has turned out that several (want-to-become) Blends could profit from the data gathered for this purpose to create their own dedicated views on the package pool. The option of some easily accessible information in some intermediate format (json) would help a lot to make even more use of the information that currently is assembled in the web sentinel. The current code makes heavy use from UltimateDebianDatabase (UDD) queries but is not very friendly regarding a simple json output. So the task would be to reuse the querying code to assemble the needed data but define a new data structure that fits into a reasonable json format. As a second step sentinel pages - in the optimal case enhanced in style and functionality - should be created from the json format. Furthermore get in contact to other projects like NeuroDebian for other output formats. Some option for user feedback on the pages would be quite interesting to have. You need to keep in mind that the tasks pages are translated into several languages - in principle we could use any translation that is used for Debian package descriptions. Currently this is implemented in static pages in the same way as www.debian.org is doing translations. If you consider some web publishing tool which might be nice and shiny but does not have the easy feature of supporting all those translations - please forget it. Translations are important and it is not acceptable to drop this feature. The tasks pages are providing direct connections to

  • http://screenshots.debian.net to enable users uploading screenshots

  • http://ddtp.debian.org/ddtss/index.cgi to enable users translating descriptions

  • http://debtags.debian.net to enable users debtagging packages

• Confirmed mentor: AndreasTille

• How to contact the mentor: mail: debian-blends@lists.debian.org

• Deliverables of the project: Web sentinel for Blends; easily accessible database containing all information about Blends packages

• Desirable skills: SQL, Python, JSON

• What the student will learn:

  • becoming comfortable with the idea of Blends

  • learn to know very different sources of information inside Debian (UltimateDebianDatabase, Debtags, etc.)

  • work together with several teams inside Debian

Get Sage ready for Debian

• Description of the project: The mathematics software system Sage is currently shipped and built together with all its dependencies. Linux distributions package the dependencies separately (mainly done in Debian, see Wiki page) and want to obtain from the Sage website only Sage itself. The Sage build system currently only supports using all dependencies bundled with Sage. The idea is to enhance the Sage build system to accept a list of dependencies, for which the version provided by the OS is used instead of the bundled one. Given that Sage robustly supports this scenario, it will not be difficult to create a Debian package of Sage.

• Confirmed Mentor: Tobias Hansen (Debian)

• How to contact the mentor: thansen@debian.org, thread on sage-gsoc

• Confirmed co-mentors: Jeroen Demeyer (Sage), John Palmieri (Sage), Julien Puydt

• Deliverables of the project:

  • support in Sage for choosing a set of dependencies that are satisfied by the OS instead of using the bundled version
  • a Sage Debian package

• Desirable skills: familiarity with build systems (e.g. Makefiles/autotools/SCons/distutils), Python, shell scripts and C libraries

• What the student will learn:

  • managing a compilation of a large, heterogeneous set of software components to create a user-friendly product
  • The student will gain equal amounts of insight into the inner workings of both a Linux distribution and an upstream software project.

• Note regarding the project proposal:

  • When submitting a proposal for this project, specify Sage as the mentoring organization. This project is also on the Sage idea page.

Automated Quality Monitoring with Jenkins

• Description of the project: jenkins.debian.net is currently in its infancy as a tool for the automated quality monitoring of Debian. In existence since the end of 2012 it currently does three major things: a.) debootstrapping of various distros in a chroot and then installing common package sets b.) installation tests with debian-installer, producing a video of the installation, again for various suites and desktops (as well as Debian Edu profiles) and c.) builds on every SVN/GIT commit of debian-installer components, manual translations as well as webchecks.

• The goal of this project would be to substantially improve this setup, by adding new classes of tests as well as generally improving things. Some examples of test classes to add (see TODO in git for more ideas):
  • run autopkg-tests for packages which have them and create jenkins jobs automatically when autopkg-tests are added to a package
  • d-i: build image on every commit and test it with g-i
  • build packages from all team repos on alioth with jenkins-debian-glue on team request (eg, via a .txt file in a git.repo) for specific branches (which shall also be automated, eg. to be able to only have squeeze+sid branches build, but not all other branches.)

• Confirmed Mentor: Holger Levsen

• How to contact the mentor: holger@debian.org or debian-qa@lists.debian.org / #debian-qa on IRC

• Co-mentors: very welcome, also "just" for one specific test-case scenario.

• Deliverables of the project:

  • at least two new classes of tests running on jenkins.debian.net

• Desirable skills:

  • familar with shell and python (all the current test cases are written as bash scripts and for Job creation and configuration jenkins-job-builder is used, which is written in Python.)
  • knowledge of Jenkins and Debian procdedures

  • please include as part of your application a patch to the current codebase which adds a jenkins job which checks whether wheezy has been released. Alternativly provide a patch which removes redudancy in job-cfg/*.yaml

  • What the student will learn:

    • how to automate tests with Jenkins
    • how Debian is made and how it can be made better

Improving PKI on Debian

• Description of the project: Many Debian packages offer SSL/TLS connectivity and use X.509 certificates to establish whether or not to trust a connection. Some packages go further, for example, using attributes from the certificate to validate individual messages passed on a connection on a case-by-case basis. The recent compromise of several certificate authorities, and the ease with which fraudsters have been able to obtain fake certificates from others, has raised concern about how much we can rely on TLS. The student will look at some of the following issues:

  • can TLS setup be made easier without compromising security?
  • making it easier for a sysadmin to store private keys at a system level and allow specified applications to use them
  • looking at ways that packages can share certificates (e.g. a mail server, SIP server and XMPP server sharing a subjectAltName certificate)
  • mechanisms for managing certificate expiry at a system-wide or site-wide level
  • centrally logging, auditing and reporting on the trust decisions made when verifying certificate chains
  • adding more fine-grained control over trust at a system-wide level: for example, declaring that some CA roots may only be relied upon to trust certificates from entities in a particular country or region
  • Looking at how alternative trust schemes (such as PGP instead of X.509) can play a bigger role in trust, particularly for RTC (SIP and XMPP servers) and eCommerce applications

• Confirmed Mentor: Daniel Pocock

  • http://lists.alioth.debian.org/mailman/listinfo/pkg-auth-maintainers

• Confirmed co-mentors: (volunteers welcome - potentially overlaps with the related project above, one-time passwords)

• Deliverables of the project: contribution to a strategic roadmap for PKI in Debian. Improvement or addition of at least one package in such a way as to help fulfill the strategy.

• Desirable skills: any one or more of the following: C, C++, Java, X.509, PGP

• What the student will learn: the student will become familiar with the details of how trust is established in secure network connections, what limitations exist in PKI and how they can be managed

Debian GNU/Hurd Debianish initialization

• Description of the project: The Debian GNU/Hurd port currently uses its own initialization scripts, which are neither really good, nor properly integrated with the rest of Debian. The goal of this project is to make this port use the default Debian init system (currently: sysvinit and its rc, sysv-rc), fixing bugs in it and in the associated init scripts, and then simply enable them instead of the GNU/Hurd upstream ones. This will probably also include integrating proper network setup, instead of the current static configuration of the pfinet translator.

• Confirmed Mentor: Samuel Thibault

• How to contact the mentor: http://lists.debian.org/debian-hurd

• Confirmed co-mentors: Pino Toscano

• Deliverables of the project: Replacing the upstream GNU/Hurd initialization with the mere use of /etc/rcS.d scripts one per one, fixing bugs along. Then just use the standard Debian init/rc system.

• Desirable skills: Shell scripting, system bootup.

• What the student will learn: This will make the student dive into how a system boots, i.e. fs check, mounts, clock setup, daemon startups, etc. both in Debian GNU/Linux and Debian GNU/Hurd

Bootstrappable Debian

• Description of the project: Bootstrapping new debian ports has historically been a very difficult process due to circular dependencies and lack of cross-build support. Work over the last 2 years, some of it under GSOC, has greatly improved the situation and demonstrated the essential functionality of the proposed solutions to these problems. But plenty of work remains to make these things practical and useable in Debian proper (and derivatives).

• The syntax for control file annotations needs to be agreed and the final version implemented and accepted in (at least) dpkg and apt. During the "Port bootstrap build-ordering tool" GSoC project of 2013 a tool which is now called botch was developed (git tree) to solve the bootstrap problem on a theoretical level. Botch works with metadata information from Packages and Sources files, allows to build a dependency graph and analyze it so that source packages which need build profiles to break dependency cycles can easily be identified. After enough source packages have been modified in practice, botch is able to calculate a build order with which (in theory) a bootstrap can be done. This year, this theoretical work should be tried in practice. The result will be a bootstrapping tool to automate the process, as well as fixes to packages and metadata. Ideally it should be set up as a continuous integration resource so that failures can be reported and the distro kept in a working bootstrappable state

  • Note: this project depends on a decision of which profile syntax to use in Debian to be useful (this thread on debian-devel). The mentors will endeavour to make this happen in a timely manner - the process is already underway.

  • Note: some of the cycles which have to be broken are 2-cycles (a list of them) where a source package depends on itself to be built. Such changes are usually quite involved and there might not be enough time to fix all of them. But only if all of them are broken, a bootstrap can be completed. It might therefore very well be that one summer is not enough to do everything.

• Confirmed Mentor: Wookey

• How to contact the mentor: wookey@wookware.org, wookey on #debian-bootstrap, #mulitarch on oftc.net

• Confirmed co-mentors: Johannes Schauer <j.schauer at email dot de> or josch in #debian-bootstrap and #emdebian on oftc.net

• Deliverables of the project:

  • Support for build profiles in all relevant tools (support for the <!stage1> format already exists and is trivial to implement in most tools)

  • Modification of enough source packages (the actual number should be between 60 and 70) to break all dependency cycles
  • Demonstration of a fully working automatic bootstrap of an existing Debian architecture from zero
  • If time permits:
    • improvements to botch like unit tests and documentation
    • a QA tool which allows developers to monitor the status of Debian's bootstrappability

• Desirable skills:

  • Debian packaging and processes, perl, C, shell
  • Botch is written in OCaml but the co-mentor is more than willing to help with it where he can

• What the student will learn: About the fascinating intricacies of linux distro bootstrapping, including multiarch and cross-building, and how to get an important piece of infrastructure upstreamed and integrated.

Package cross-building continuous integration

• Description of the project: Cross-building support has become important as ARM development has become a major focus, but fast ARM build hardware remains rare. A lot of core work has been done to make this a reality in Debian, with multiarch and improved toolchain support. But most package maintainers are not aware of this, nor of the status of their packages. And many, many packages remain to be fixed. Continuous cross-build testing of packages and reporting the status in the Package Tracking System (http://wiki.debian.org/qa.debian.org/pts) would enable distribution of the large task of making this work everywhere.

• This needs cross-build infrastructure to be set up and integrated. A cross-aware buildd running cross-builds of new uploads for multiple target architectures, scripts to deploy such instances on (virtual) servers, PTS integration, web UI reporting current status and regressions. Many of the parts for this already exist to some degree, but code is needed for buildd cross-awareness, deployment, PTS and UDD integration and regression reporting. As well as an infinite amount of actual cross-build bug-fixes.

• Confirmed Mentor: Wookey

• How to contact the mentor: wookey@wookware.org, wookey on #emdebian, #mulitarch on oftc.net

• Deliverables of the project: A continuously running cross buildd reporting status into the debian Package Tracking System.

• Desirable skills: Debian cross-build mechanisms (https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingMultiArch), soap/LDI, scripting languages (perl/shell/python)

• What the student will learn: The importance and practicalities of continuous integration testing. Integrating code across multiple subsystems. How build daemons work

Improvements to Debian Search

• Description of the project:

  • Debian has a search for its website (http://search.debian.org/) and for the mailing lists (http://lists.debian.org/search.html), both of which are powered by Xapian and its CGI front-end, Omega.

  • While these generally work well, some common searches return disappointing results - for example, in the website search, "dfsg" brings up a lot of Debian Security Announcements, while "wheezy" or "squeeze" returns release notes (these are relevant, certainly aren't the best answers).
  • Xapian uses a weighting formula called BM25, with 5 tunable parameters. We likely could improve the results by tuning these parameters, but a more interesting approach would be to implement some of the Divergence from Randomness (DfR) weight schemes. Many of these are "parameter-free", and yet academic studies show they usually outperform BM25 (and other weighting formulae). The DfR scheme know as "DPH" is particularly interesting as it's reported to be resistent to keyword spamming - the issue with the "dfsg" example is that the DSA pages repeat "dfsg" a lot, which isn't intentional keyword spamming, but the effect is the same.
  • Enabling Xapian's spelling correction feature would be useful, as another reason for poor results is a typo or spelling mistake in the query.

  • We should also investigate making use of relevance feedback - this is a feature which allows Xapian to suggest extra words to add to the query, and this provides an easy way for the user to iteratively improve their search results - for an example, see the green box here: http://xapian.org/search?P=bm25

  • The above certainly isn't an exhaustive list of search-related things that could be done, so if you have other suggestions you're interested in working on, please come and discuss.

• Confirmed Mentor: Olly Betts

• How to contact the mentor: ol on #debian-soc on oftc

• Confirmed co-mentors: Dan Colish (dcolish)

• Deliverables of the project:

  • Implementations of the more useful DfR weighting schemes for Xapian
  • Spelling correction deployed
  • Relevance feedback integrated into the searches

• Desirable skills: C++, HTML

• What the student will learn:

  • Learn more about Information Retrieval
  • Hone your C++ skills
  • Get to have your code deployed on a popular website

Debian Android Application

• Description of the project: Debian Developers utilize many online resources on a daily basis in order to properly maintain their packages. Some of these tools include the PTS, BTS, and UDD. It would be nice to have all of this information readily available on a phone/tablet via an android application. The application would use existing Debian APIs to fetch and display all of the information. For things like the BTS, it might support functionality similar to reportbug.

• Confirmed Mentor: Hans-Christoph Steiner

• How to contact the mentor: mail: hans@eds.org, IRC: _hc on OFTC and freenode

• Confirmed co-mentors: To-be-discussed (please join me!)

• Deliverables of the project: The ideal final result of this project would be an Android application that is either distributed via the Google Play store (for free) or available for download from a Debian website.

• Desirable skills: Android Application Development, Java

• What the student will learn: Students will gain experience with the many tools Debian Developers utilize on a daily basis, which will prove useful if they decide to become a Debian Maintainer/Debian Developer in the future.