Summer of Code 2008

From openSUSE

(Back to the main Summer of Code page)

This is our page of ideas for the Google Summer of Code 2008. If you are a student, you can participate by developing one of the projects we describe here (or propose an idea of your own!), and wish cash prizes! You will be mentored by an experienced member of the openSUSE community.

Are you a student? See information for students below.

Do you want to mentor a student? Start by reading the Summer of Code Mentoring HOWTO. Then, register yourself as a potential mentor.

Information for students

The Google Summer of Code is a program for students in most countries. You will participate by writing code for a free software project. Students who finish their work satisfactorily will win 4500 US Dollars!

Do this if you want to participate:

1. Start by reading the general information for students participating in the Summer of Code.
2. Register yourself as a participating student.
3. See which of the projects below you find interesting.
4. In your student page, write a proposal about the project you picked.

Your proposal should include this information:

• Give a detailed idea of what you want to accomplish in your project. Don't just quote what the project's abstract says! Think of how you will actually implement it, and describe that.
• Give a general idea of your skills. If you have participated in a free software project before, say so and if possible point to your contributions.
• Give a rough timeline for your work, with milestones. For example: "week 1, get the code to build and start familiarizing myself with it. Week 2, implement the first refactoring patch. Week 3, try such and such thing."

Basically, let us know why you are the perfect person to implement the project you picked :)

Important dates

(Copied from the SoC 2008 FAQ)

Subscribe to this calendar (FIXME: using "webcal://" doesn't work in the wiki. How do we enable that URI scheme?)

March 3: Mentoring organizations can begin submitting applications to Google (~12 noon PST/19:00 UTC).

March 12: Mentoring organization application deadline (12 noon PDT/19:00 UTC).

March 13-17: Google program administrators review organization applications.

March 17: List of accepted mentoring organizations published on code.google.com/soc/ (~12 noon PDT/19:00 UTC).

Interim Period: Would-be student participants discuss application ideas with mentoring organizations.

March 24: Student application period opens (~12 noon PDT/19:00 UTC).

March 31: Student application deadline 5:00 PM PDT/00:00 UTC April 1, 2008.

April 07: Update: Student application deadline extended to this date!

April 18: All mentors must signed up and all student proposals matched with a mentor by 00:00 PDT/07:00 UTC.

April 21: accepted student proposals announced at code.google.com/soc/ (~12 noon PDT/19:00 UTC).

Community Bonding Period: students get to know mentors, read documentation, get up to speed to begin working on their projects.

May 26: Students begin coding for their GSoC projects;

July 7: Mentors and students can begin submitting mid-term evaluations (~12 noon PDT/19:00 UTC).

July 14: Mid-term evaluations deadline at 12 noon PDT/19:00 UTC;

August 11: Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.

August 18: Firm 'pencils down' date. Mentors, students and organization administrators can being submitting final evaluations to Google (~12 noon PDT/19:00 UTC).

September 1: Final evaluation deadline 12 noon PDT/19:00 UTC.

September 3: Students can begin submitting required code samples to Google

List of projects

Making removable hard drives Just Work(tm)

When you plug in a blank external hard drive (say, by USB), nothing happens. The device gets created (e.g. /dev/sdb), but if the drive has no partitions, nothing else happens.

The system should detect this situation, and offer you some options. For example:

You have plugged a blank hard drive.  Would you like to:

  (o) Back up your system
  ( ) Prepare the drive to store Linux-only files
  ( ) Prepare the drive to share files between Linux and other systems
  ( ) Ignore this message

The drive would be partitioned / formatted as appropriate. If we find a backup solution, we could use it then.

HAL needs to be extended to provide interfaces to partition and format drives. Authorization for these need to go through PolicyKit. The user-visible work needs to be done for GNOME and/or KDE.

You would be in contact with your mentor and the HAL / PolicyKit maintainers.

Required knowledge: HAL, PolicyKit, GNOME/KDE programming, some system-level disk stuff

Skill level: medium

Willing mentors: Federico Mena Dirk Mueller

Reliable unmounting of removable media

In GNOME sessions, you can right-click on the icon for a removable volume and select "Unmount volume" or "Eject". However, if the device is in use, you just get an error message saying so. GNOME should tell you which processes are using the volume, and offer you the chance of killing them.

Alternatively, you could use the revoke() system call to disconnect processes from certain file descriptors, and hope that they react gracefully later.

Required knowledge: C programming (for Nautilus), fuser, lsof, low-level system calls

Skill level: medium

Willing mentors: Federico Mena

YaST ideas

See YaST Research Page.

Libzypp Download Failover

Mirrors of download.opensuse.org are used extensively by libzypp/YaST. As mirrors are often unreliable, users can experience situations where something doesn't work as expected. libzypp should be able to recover as graceful as possible and continue to work. After all, there are usually many mirrors available for fallback - so libzypp should be enhanced to make use of them for failover.

The download redirector running on download.opensuse.org offers ways for libzypp to implement this. One of the features of the redirector is to give a client a dynamic mirror list. With that list, the client could do powerful things like failover (when a mirror has died, is not reachable, times out, sends a broken package, ...), select the fastest mirror, or other things.

A concept how this can be implemented is here.

Required knowledge: C, C++, cURL library, HTTP protocol

Skill level: medium

Willing mentors: poeml, duncan

GTK+ Version of the installer

A previous SoC project resulted in the GTK+ front-end for the YaST control centre but the Qt version of the installer is still required even on the GNOME CD. On the other hand Qt 4.x brought features used now in the installer that GTK+ lacks like CSS branding.

• Implement the installer in GTK+.
• Make it possible to create an install CD using said installer.
• Implement all features like branding.

Required knowledge: C/C++, YaST2, Gtk+

Skill level: medium-hard

Willing mentors:

openSUSE BuildService Ideas

BuildService RSS and KDE4 plasmoid feed

There should be a RSS feed available to watch build service projects you're interested in for new build failures, as well as being able to watch projects for changes (new patches, version updates). Bonus point would be to integrate the news feed as a KDE4 plasmoid, KDE4's plasma makes it easily possible to have useful information permanently on the desktop background.

Required knowledge: Ruby, RSS, optionally Plasmoid (Javascript or C++)

Skill level: easy - medium

Willing mentors:

BuildService <-> Eclipse Integration

In Eclipse there should be a native mode to work with Buildservice Projects and Packages, see their build status, adjust them etc.

Possibly that could be integrated with http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-contrib/org.eclipse.cdt.rpm-home/index.html?root=Tools_Project&view=co which is a rpm spec file integration for Eclipse.

Required knowledge: the Eclipse Platform, buildservice api (XML, REST)

Skill level: medium

Willing mentors: ideas available ;-)

GNOME Build service client

A simple GNOME front-end was started during hack-week II to provide easy access to the build service in openSUSE. It was just a simple start, so extending it to provide access to all build service features would help developers a lot in managing their projects. The openSUSE build service provides a way for developers to distribute their software for several Linux distributions and architectures, it is just one of the best things about openSUSE, but since its usage, via osc, the command line client, or via the web interface is not as easy as expected for some users, an easier and more integrated with the way developers work way, right from the users' desktops, to manage their software in the build service, would help a lot in spreading the usage of this fabulous openSUSE service.

Not only should it provide access to all build service commands, but it should provide the needed infrastructure to provide access to those commands in the easiest way for the developer, offering convenience features (like creating spec files from templates, adding known commands to the .spec file, etc) to make the job as easy as possible. Lots of other ideas have been coming up from different places, like providing seamless integration with upstream releases (getting notifications when a new upstream release is published and submitting the tarball directly to the build service), building and publishing packages, etc.

It should, in short, make packaging as easy as to allow anyone with basic knowledge publish their software through the openSUSE build service. If it succeeds, lots of developers will love using the build service for distributing their software.

Current code is available at:

git clone http://www.gnome.org/~rodrigo/git/osc-plugins.git

Required knowledge: Python, GTK+

Skill level: medium

Willing mentors: Rodrigo Moya

OpenID support for the Build Service

OpenID is an open distributed authentication system, which allows users to use one account to login to many web sites, while giving them full control of how account data is used. If the openSUSE Build Service would allow OpenID logins, users wouldn't have to create extra accounts to be able to use the Build Service.

The task of this project is to add OpenID support to the Build Service, so that it's able to act as OpenID consumer, allowing users to login with their existing OpenID account. One of the challenges of this project is to find a way how users can manage multiple accounts and relate them to each other, e.g. to establish equivalence of a Novell login and an OpenID account of the same user.

Required knowledge: Ruby would be an advantage, as the Build Service web interface is written in Ruby. OpenID experience would be a plus as well. Both can be learned while going, though.

Skill level: medium

Mentor: Cornelius Schumacher

Source Upstream Integration

Currently all source tar balls get uploaded to the build service by the packagers. This is first of all not nice for the bandwith usage for packagers, but more important, it is bad to verify source tar balls later on comming indeed from upstream project.

Based on the client tool and specification for the source upstream integration this system can get improved by:

• Adding verification support via MD5SUM, gpg and/or further mechanism. The current spec for the _upstream file format need to extended for this.
• Adding support for executing download on the server side.
• direct integration into osc command line tool (optional)

Required knowledge: Ruby, Python (optional)

Skill level: medium

Mentor: Adrian Schroeter

Hermes Notification System

The Hermes Notification is a new part of the openSUSE infrastructure that helps the user to receive notifications about the events happening in the Buildservice like new project- and package creations, builds successes and failures, change requests etc. All these events create Messages in Hermes and the user can decide if, in which way and how often these informations shall reach him. Messages can be combined to digest messages and sent through a variety of methods like mail, jabber, RSS etc.

Hermes is not bound to the openSUSE Buildservice. Other systems that send around a lot of mails which want to be a bit more user friendly and let the user specify how the messages reach him, can use and benefit from Hermes.

There is already some code and functionality for Hermes but there is still lots to do to make Hermes ready for the community. Help here would be highly appreciated.

Required knowledge: Ruby, Perl, HTTP

Skill level: medium

Mentor: Klaas Freitag

Yet Another Build Service Client (yabsc)

Yabsc is a build service client which focuses on reporting project and package results. It is written in Python using the PyQt4 and osc libraries.

There are a number of potential features that can be added: systray notification, advanced result filtering, buildlog searching, and maybe even package/project editing.

Required knowledge: Python, Qt

Skill level: easy - medium

Mentors: James Oakley, Dirk Mueller

OpenSync / KDE4 integration

OpenSync is a platform and distribution independent synchronization framework. During the KDE4 transition, user configuration has to be ported over from KDE3 to KDE4, and also kept in sync. This could include application configuration, and user data like KWallet entries. OpenSync is the most obvious solution for this.

Required knowledge: A scripting language or C++

Skill level: easy-medium

Willing mentors: Daniel Gollub, ...

Interactive Crash-Analysis

openSUSE provides debuginfo packages which help providing usable backtraces for application crashes. Currently however, the user is required to manually figure out which debuginfo packages are necessary, then install them and afterwards try to reproduce the crash. Part of this proposal would be to write a tool to capture crashes as they occur, to analyze the coredump, figure out which debug information is needed, to offer the user to download it, and then afterwards generate a backtrace and clean up the debuginfo/core dump.

Required knowledge: A programming language, DWARF-tools, gdb, crash analysis.

Skill level: medium

Willing mentors: Dirk Mueller, jblunck at suse dot de

/etc/sysconfig Wizard

Currently, openSUSE system configuration is stored in text configuration in /etc/sysconfig, which can be edited via a tree-view based yast editor (or any other plain text editor). Part of this proposal would be to develop a wizard mode, which means that the user can, upon installation of a new package or alternatively by a manual reconfigure, be asked questions in a sensible way, and interactively configure important system configuration. It can also be used to configure additional software in a uniform manner (for example during installation of a SQL server package or similar). Ideally, the wizard should be prototyped in YaST UI to be reusable across all desktop environments and in text mode.

Required knowledge: deb-conf knowledge preferred, admin experience, YaST

Skill level: medium - hard

Willing mentors: Dirk Mueller

enable ext4 file system as boot partition

Now ext4 is merged into official kernel as ext4dev. Several popular distributions also plan to adopt ext4 in product. Unfortunately, ext4 can not be used as boot partition, because grub (the most popular bootloader used in most of the distribution) does not support ext4 partition. In order to enable ext4 file system as boot partition, an ext4 stage 1.5 of grub is needed. The new stage 1.5 should support incompatible feature of ext4 file system, provide read-only access method of ext4 partition. Development is based on grub legacy, so the result can be adopted by OpenSuSE very soon.

Required knowledge: kernel development skills, general file system conception and basic knowledge of ext2/3 file system.

Skill level: hard

Willing mentors: Coly Li

Video4Linux API for Applications

Applications using webcams and capture cards need to implement all of the details of the Video4Linux interface on their own. This is complex, requires the applications to hunt down or implement all of the format conversions on their own and creates dozens of divergent interpretations of the spec.

To help application developers a client/server API needs to be developed that can solve the following issues: multiple applications getting frames from a device at once, convert frame for an application, simple manipulations like rotation of frames for applications.

It would be possible to adapt the Kopete video4linux layer into a general purpose library for webcam access.

Required knowledge: C, willingness to learn video/image formats

Skill level: hard

Willing mentors:

• Brandon Philips
• Will Stephenson

Migration Assistant Reloaded

MacOSX contains utility Migration Assistant which imports users, application, settings and various files from old Macintosh to new one. In GSoC 2006 Ubuntu held project 'Ubiquity Migration Assistant' to create something similar but allowing import from Windows systems. Unfortunately this had been coded in C which is pretty hard to extend and maintain. I'd like to rewrite this from scratch using objects and abstraction (probably C++). Support for new OS like Windows Vista and MacOSX Leopard is also desirable. Project concept and OS detection is done.

Goals/Features:

• detect operating system on mounted partition (can be Windows, MacOSX, GNU/Linux, *BSD) - DONE
• detect users, documents (email, bookmarks) and settings in mounted operating system
• import data from first OS (eg. read bookmarks from Internet Explorer into generalized format)
• export data to second OS (eg. write bookmarks to Mozilla Firefox)
• extract wifi firmware from Windows, Windows driver CD, another Linux and wrap binary into ndiswrapper

optional:

• import soundcard settings (for legacy cards)
• create GUI in Qt4
• create YaST module

Required knowledge: C/C++, Linux config files, Windows registry, Qt4 (optional), YCP (optional)

Skill level: medium-hard

Willing mentors: Pavol Rusnak

LTSP GUI Management for openSUSE

A tool to make setting up and modifying LTSP settings an easy task.

Features:

• Avoiding manual editing of config files in a production environment.
• Keep a history of all your edits with rollback functionallity to walk back and forward through your setup changes.

Have a look at Ubuntus LTSP-Manager for an idea...

Ideas and a first draft can be found on the Easy-LTSP page. Feel free to enhance it.

Or perhaps make this a project to port Ubuntu's LTSP Manager to openSuSE, assuming it is GPL or course.

Required knowledge: Depending on the used GUI: ycp (YaST), KDE or GNOME, some knowledge of openSUSE internal for storing config files.

Skill level: medium

Willing mentors:

• User:Cyberorg
• User:lrupp

LimeJeOS and cocktail.lin.cat ideas

LimeJeos is a project for building a base for software appliances. It is part of the cocktail.lin.cat project. The last is a project for building a web interface for building software appliances using LimeJeos, Eis and KIWI.

LimeJeos is being built based on openSUSE and as a community project. That means that, even though Novell-openSUSE is participating on the discussion and as advisor, the project is not being managed by Novell people, but by an openSUSE member.

What is very important also is the relation between this project and the build service, as the last one is the base for the Eis part, that is where the software will be.

Building a prototype for the web interface

Even though the web application implementation has started, there are only very few rough designs of how the web interface will be like. The web application implementation it is now being focused on building a core functionality so it can be used as a common framework, but it is not yet oriented to the end user.

So, a first prototype is needed in order to get community feedback, on the requirements, but also, and not least important, on the interface and user experience. This prototype will be used as a base for the final application interface and design. So, it should be done using HTML, CSS, Ajax, be standard complaint, be accessible, and look nice!

The student will be working with a graphic designer that will design the logos and give some advice on the general layout and colors.

Required knowledge: HTML, CSS, Ajax and some Javascript.

Skill level: medium

Willing mentors: User:Jordimassaguerpla

Building a media center appliance

As said, LimeJeos is the base for software appliances. One software appliance that will be cool to implement is a media center one. That will be an openSUSE based distribution that will have only the media center software and its dependencies, not even GNOME nor KDE nor any other Desktop. On startup, the software appliance should start the media center (it will need to start the X-Window system too), and all the configuration will be done from the software appliance, as well as shutting down the system.

So, knowledge on media centers (Myth or Elisa for example), not only on installing them but on modifying them, building RPMS, modifying the openSUSE installation, will be either required or acquired during the project.

Required knowledge: Some knowledge on media center software, on installing but also on programming them (at least the language which is programmed).

Optional knowledge: Building RPMS, building either Xen,vmware, livecds, usbstics, isos, ... using kiwi.

Skill level: medium

Willing mentors: User:Jordimassaguerpla User:Avengermojo

Building a detection intrusion appliance

As said, LimeJeos is the base for software appliances. One software appliance that will be interesting to implement is a detection instruion one. That will be an openSUSE based distribution that will have only the snort tools and their dependencies, not even GNOME nor KDE nor any other Desktop. This appliance should be accessible and managed through a web interface, possibly meaning the integration of a web management application like webmin.

So, some good knowledge on snort and intrusion detection will be required. Also some knowledge on building RPMS will be interesting.

Required knowledge: Some good knowledge on the intrusion detection software snort and its administration through a web interface.

Optional knowledge: Building RPMS, building either Xen,vmware, livecds, usbstics, isos, ... using kiwi. Webmin and some basic php knowledge.

Skill level: medium

Willing mentors: User:Jordimassaguerpla

Game server status alerter

A gui-configurable daemon that scans the local network for online game servers every n minutes, where n may be set by the user. It alerts the user by a popup message on the taskbar and also gives her information such as number of players, map currently being played, and ip address of the server. It lets gamers, especially the ones who game on Windows, spend time on Linux without worrying about their games starting without their knowledge.

The required, pure C++ daemon has existed for years as part of KDE 3 and can be found in our kdenetwork3-lan package. A partial port of the UI to KDE 4 also exists. It would be possible to extend the daemon to scan game servers ports and the ioslave to display them in Konqueror, and/or write a GVFS plugin that would talk to the daemon to display the scan results in GNOME.

Required knowledge: C/C++, Gtk+ or Qt, some sockets API

Skill level: easy-medium

Willing mentors: User:Wstephenson

Integration of various online translator tools

To improve the workflow of translation teams, various online tools can be used:

• damned-lies is a software developed by GNOME to collect statistics about GNOME translations. See http://l10n.gnome.org/
• vertimus is a system to organize the workflow in a translation team. See http://gnomefr.traduc.org/suivi/ for a demo.
• POAT is similar to vertimus.
• Transifex is a web-system that facilitates the process of submitting translations in various version control systems (VCS), developed during Summer of Code last year.
• pootle is a web-based translation system.

The project would consist of working on making some of those tools work with each other. An example of complete online workflow could be: see that a module needs a translation update via the statistics displayed by damned-lies, reserve the module for translation in vertimus, translate the strings in pootle, have someone proofread the new translations in vertimus/pootle and have someone use transifex to commit the updated po file.

Required knowledge: python, HTML, maybe php

Skill level: medium

Willing mentors: Vincent Untz

Bugzilla Desktop Client

Write a desktop application that serves as a frontend to bugzilla, using the XML interface. Features that come into mind:

• Support for multiple bugzilla instances
• consistent look & feel regardless of bugzilla instance and phase of moon
• Speed :-), e.g. 'edit' search ideally doesn't require any roundtrip to the server, same for "Advanced Searching Using Boolean Charts". Generally, such client could remember much more than the we ui can store in cookies and it should exploit this.
• automatic relogin
• Saving unfinished replies as drafts.
• There is already KDE KBugBuster in openSUSE, it would need extending to support the Novell version of Bugzilla. A rewrite was begun to clean up the design and use a clean model/view architecture, this is in KDE SVN.
• There's a thing called Deskzilla, get inspired. There's also the FATE kde client which does a similar thing for our feature tracking system.

Required knowledge: design of GUI applications, XML

Skill level: medium-hard

Willing mentors: User:Michal-m (but someone more skilled in GUI programming would be more suitable mentor), like User:Wstephenson

Icecream distributed compiling improvements

Icecream is a distributed compilation system that is developed by SUSE and used for building SUSE packages. It lacks a couple of advanced features that would be nice to have:

• automated blacklisting of faulty compile hosts
• use of librsync for distributing the compiled source or binaries to reduce network traffic (especially useful for distributed compiling over wireless LAN).
• scheduling tweaks
• using real benchmark jobs to detect system speed
• improvements in the automatic detection of schedulers (broadcast vs. multicast)

Required knowledge: C/C++

Skill level: easy-medium

Mentor: Dirk Mueller, Michael Matz

New approach for (RPM) packages creation

The packaging for Linux distribution is too much complicated. The rpm-based distributions has a specs, deb based uses a debianized sources, ... There are some different concepts (based on BSD ports), like Gentoo Portage and OpenEmbedded BitBake, which are more dynamic and provide a higher level of abstraction in packaging process as spec files does (for example lang files subpackages).

There are two project - Packaging wizard and Abstract Package Build Description, which attempt to find and create a new (high level) approach to package creation process.

This approach is mainly based on question/response mechanism and constructing of a abstract tree, which represents the packagers mind (in concrete - his actions) and is developed with distribution independency in mind. This abstract description should be converted to concrete represenation (with comformity to Packaging Conventions of current distributions, so the specfile for Suse should be different with spec for Fedora).

The student should improve the APBD, or create a new tool based on ideas from pwiz and APBD.

Required knowledge: programming (bash, ruby, python), create packages for Linux distribution (ideally a rpm)

Skill level: medium

Willing mentor: Michal Vyskocil (Co-mentor: Standa Brabec)

Qt/KDE Front-Ends for PackageKit

PackageKit is a system designed to make installing and updating software on your computer easier. The primary design goal is to unify all the software graphical tools used in different distributions, and use some of the latest technology like PolicyKit to make the process suck less.

The student should write Qt or KDE-based front-ends for PackageKit (either based on dead QPackageKit or start from cratch) which allow the most common tasks (update, software install/deinstallation, repository configuration, ...).

UPDATE: It seems work on a KPackageKit has already been started in PackageKit repository so this would require some coordination/discussion.

Required knowledge: C++, Qt, optional KDE

Skill level: medium

Willing mentor:

Qt/KDE4 Front-End for Compiz

Compiz Fusion is a project that gathers plugins, tools and other Compiz related work. Compiz is a composite window manager with a flexible plugin design which has allowed for many interesting window manager concepts.

Compiz Fusion currently offers CompizConfig Settings Manager (ccsm) which uses libcompizconfig to allow total control over every aspect of Compiz. CCSM is written using GTK and is mainly intended for developers and advanced users. The student should write an alternative using Qt4, with more focus on the end user than ccsm currently offers.

Required knowledge: C, Qt, some Compiz

Skill level: medium

Willing mentor:

Synchronizing Wallets/Keyrings between computers

The secure storage of user secrets (website, email, IM passwords, WiFi credentials...) on Linux has two problems: Firstly, users often have more than one machine and secrets are not shared between them. Secondly, KDE, GNOME and Mozilla all have their own separate secret stores.

This project is to develop plugin(s) for the OpenSync framework to solve this problem. OpenSync provides a robust sync engine with the format conversion and conflict detection infrastructure to enable a safe synchronization of this important data.

The project would divide into several parts: for syncing across multiple machines: accessing the data to be synced in a safe way, since this is stored in encrypted files and is normally accessed via an API that does not allow network access to the data. This would need to prevent concurrent access while the secrets are being synced. Secondly, implementing a plugin to access the data and feed it to the OpenSync sync engine. Thirdly, format conversion plugins to convert between different secret stores' data representations.

This project would be of benefit to openSUSE users and the wider Linux desktop community.

Required knowledge: C, C++, Qt, ability to get into different APIs quickly.

Skill level: medium

Willing mentor: User:Wstephenson