二零零八编程之夏

本文处于需要翻译的文章的状态，欢迎您积极参与翻译与修订。 翻译人员：无，修订人员：无。

(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: Udpate: Student application deadline extended to this date!

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

April 14: 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

Make YaST more IPv6 compatible

Now YaST is not able to set up static IPv6 routes and not able to setup IPv6 tunnel. Student should make YaST network module able to setup static IPv6 configuration and create a new one IPv6 tunnel configuration module.

This module should be able to setup basic IPv6 tunnels.

• AYIYA
• 6to4
• 6in4
• Heartbeat

That AYIYA and Heartbeat should have be compatible with SixXS broker, but there could be possibility to change to other providers. 6in4 should be able to handle all providers but a few providers can be mentioned in help. 6to4 is anycast using tunnel.

Required knowledge: YCP, IPv6 routing, iproute2, aiccu

Skill level: medium

Willing mentors: Maybe mzugec, maintainer of yast2-network, kmachalkova, maintainer of yast2-network and yast2-heartbeat

YaST web user interface

YaST is a power component framework that can interact with components written in different languages, and it is the only successful 1:1 system management tool.

In the age of web 2.0, we would like to bring YaST a web user interface. This means:

• Figuring out which approach to use
  • Rewrite modules user interface (generate a prototype for some) and use the YaST components.
  • Make current modules to work, by leveraging the pluggable user interface and something like the Witty toolkit.
    • There is a current prototype http://svn.opensuse.org/svn/yast/branches/research/ , needs to be ported to the lastest libyui "modular UI" changes
  • Figure out issues like sessions, concurrency, etc.

Required knowledge: C++, some AJAX, a web-toolkit would be good, YaST2 useful

Skill level: hard

Willing mentors: michael dot meeks at novell.com

YaST PolicyKit integration

YaST right now assumes you are root.

• Define a framework to leverage something like policykit to allow YaST to perform tasks without being root, based on system policy definitions.

Required knowledge: C++, D-BUS, YaST2, ycp useful

Skill level: hard

Willing mentors:

YaST PolicyKit configuration module

Since PolicyKit get integrated more and more into the system we need a YaST module to edit the policy settings.

There are for example currently already 27 different policy rules for HAL alone (plus may more in other tools in the future). We need a way for the admins to change the rules to allow/disallow e.g. the user to suspend, change the CPU frequency or mount internal/external volumes.

Required knowledge: PolicyKit, ycp useful

Skill level: easy

Willing mentors:

Notes: Note that there is already prior work in having a GUI to configure PolicyKit: screenshot 1, screenshot 2, screenshot 3. It may not make sense to write a YaST module from scratch.

YaST Webcam module

YaST currently does not provide a generic way to configure your webcam. Listing the detected devices and performing the necessary steps would be part of the module. It has to be developed within the community for testing / feedback and collecting quirks of all existing hardware.

Required knowledge: YCP, Python or Perl, v4l/webcam knowledge

Skill level: medium

Willing mentors: Dirk Mueller

Make YaST Independent of YCP

YaST has its own language which is not very popular. We have support for perl components, and since recently, support for Ruby and Python is here.

• Now that libyui is independent of YaST, we need to leverage it without YCP, defining nice APIs in popular languages
• There is a prototype to convert ycp code to xml and then to ruby, which can be used to move _some_ functionality
• There is a prototype of a MySQL server module written in Python.

Required knowledge: Ruby or Python, C++, YaST2, languages, parsers, compilers

Skill level: hard

Willing mentors: dmacvicar

Automatic generation of YCP bindings

Right now, if you want to access low level libraries from YCP code, you have two options:

• Create manual bindings, may be with help of /usr/share/YaST2/data/devtools/bin/generateYCPWrappers script. (used by package-bindings and libyui ycp bindings )
• Wrap your library using swig, and then generate perl bindings from that, and then use the module using YaST perl bindings (libstorage is accessed this way).

This problem could be solved in various ways:

• Create a SWIG module that allows ycp glue as output.

This approach would get all the swig parsing magic for free.

• Extend generateYCPWrappers so it could wrap any C library in a easy and automatic way. C++ is not required, as YCP is not object oriented.

Expected result:

Get package bindings or libstorage output which don't depend on perl bindings and are automaticaly updated if the target API changes.

Required knowledge: C++, YaST2, languages

Skill level: medium

Willing mentors: dmacvicar

Build YaST using cmake

YaST builds using autotools and a automated layer of scripts over that (called y2conf, y2make, etc).

Some modules as libzypp and friends, yast2-qt and ruby bindings build using cmake.

It would be great to build complete YaST using cmake. This would bring benefits like:

• Access to the CTest test framework
• out of the box out of source builds
• Easier and more intuitive.

This task means:

• making yast2-core to compile using cmake
• create devtools skeletons for modules and agents using cmake
• add support for devtools utilities which may break
• port all modules. (porting 3 would be a challenge, the others is mostly mechanical work once core and some problematic ones compile). Automating the conversion would also be a goal.

Required knowledge: cmake, building, packaging

Skill level: easy

Willing mentors: dmacvicar

Integrate YaST into KDE 4 SystemSettings

Integrate YaST modules into KDE 4 SystemSettings

• Instead of having two separate applications to configure one's system, integrate the YaST modules into SystemSettings and also eliminate duplicated functionality.

Required knowledge: C++, Qt, YaST2 (?)

Skill level: low or medium (?)

Willing mentors:

There is already ongoing effort on a new version of the control center based on System settings concept, but not to integrate with it. http://svn.opensuse.org/svn/yast/branches/tmp/tgoettlicher/yast2cc_rewrite/

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

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