Contact Bryan Østergaard at kloeri@exherbo.org or kloeri in the #exherbo channel on irc.freenode.net for further information.
Develop a client using the Paludis library to extract metadata from Exherbo packages and check for new upstream versions. The client should be able to deliver the reports using several different interfaces. At minimum it should be able to generate a text based report locally as well as be able to mail the report and show it using a web interface.
Furthermore it should be possible to configure the client to generate reports for a subset of package repositories, package categories or specific packages.
For bonus points the client should also be able to show related data such as ChangeLogs or Release Notes when Exherbo packages contain enough metadata for that.
Applicants should be familiar with Ruby, Python or C++ and have some knowledge of website development.
Build an application that can create image files useful for installing Exherbo or testing it.
The application should be able to build a number of different formats such as:
CDROM/DVD images
USB stick images
Images for virtualization products such as kvm or vmware
Users should be able to specify the partition layout, which packages to install in the image as well as any needed configuration for boot loaders, kernel configuration etc.. The application should work for both x86 and amd64 based images and be designed in such a way that it’ll be possible to add further architecture support to it at a later point.
This project can be implemented in just about any language but the obvious choices would probably be scripting languages like Bash, Ruby or Python. Experience with partition and bootloaders would be an advantage but not a requirement.
We already have a very basic script for creating raw images (app-virtualization/exherbo-vm-utils::replica) written in bash but it’s likely better starting over and basing the work on libguestfs or similar.
We’re currently downloading source tarballs and other distribution files needed for package building using rsync, wget and similar tools. It’s possibly to optimize bandwidth and storage requirements quite a bit if we instead use git for distfiles management.
The plan is approximately as follows:
Unpack all distfiles on the distfiles mirrors
Store the files in a git repository and tag them according to the package version
Clients updates to the requested version (git tag) taking advantage of similarities to earlier version(s) already downloaded
You need a fair understanding of how git works as well as how Paludis fetchers work. This project may include some work on git as we’d want to investigate shallow clones or similar options to save even more bandwidth and storage space.
Exherbo doesn’t have a proper framework for handling external kernel modules like the binary blobs used for some video or wireless cards.
You need to:
Figure out what’s needed for the user interface
Find out what special needs exheres packages have when dealing with external modules
Determine how much support can be done in exheres packages or exlibs and how much support is needed in Paludis itself
Become famous for implementing this much needed feature that people have talked about for at least two years already :)
Implementation language(s) will be bash and C++ for the exheres/exlibs and Paludis side respectively. A good starting point is to read the many discussions that’ve already taken place on the exherbo-dev mailing list. You can find one of the discussions at Handling of kernel modules but I’d recommend perusing the list archives for more information and ideas.
Exherbo splits packages into different package repositories so we have all KDE packages in one repository, network related packages in another package repository and so on. This is a fairly good way of splitting up thousand of packages and also makes it possible for different groups of contributors to have push access to different types of packages without much administration at all.
But it also means that all Exherbo users end up with quite a few package repositories installed and that users somewhat frequently installs new package repositories. To make this easier we need a feature called RepositoryRepository which is a repository with enough information about other repositories to allow installation and removal of repositories through the package manager.
You need to be familiar with C++ and may also need some bash knowledge.
Genesis is a new event manager / init system written from scratch. It’s fully event driven and it’s reasonably easy to implement new event sources.
Interesting sources include:
SELinux events (there’s a NETLINK_SELINUX socket you can use)
Audit events (NETLINK_AUDIT)
Events from Apache HTTPD or other web servers so administrators can trigger scripts on page hits and similar. This would require investigating the server application to see if it has any way of exporting events and possibly writing a module adding that support. Administrators could use the support to easily create custom logging rules, dynamic firewall updates when seeing suspicious traffic or automatic scaling according to server load for example.
Implementation language(s) will primarily be C++ but knowledge of C and bash is likely needed as well.
The new Paludis client cave has lots of options to control dependency resolution. In many cases this is a bit of a hassle as you have to run ‘cave resolve’ repeatedly adjusting command line options until you get the desired package resolution.
One way to improve to handle this is adding a ‘git add -i’ style option to Paludis so users can interactively change the resolution.
You need C++ experience for this project and some experience with Paludis and Exherbo will be needed as well.
A client/server based application collecting and displaying a variety of statistics about package use on client machines.
The client part should gather information using the Paludis library bindings and submit them to the server. The server part is responsible for receiving all the data and providing a web interface where users can show statistics from the collected data, filtering and sorting the data as needed.
Security is an important part of this project as all collected data must remain absolutely anonymous. If data is leaked that can identify either persons or machines this can harm our users as well as the Exherbo project.
The student is well advised to look at Debian and Ubuntu’s Popularity Contest (see http://popcon.debian.org and http://popcon.ubuntu.com) for existing implementations of this idea and inspiration.
This project is easiest to implement in Ruby or Python but can be implemented in C++ or a combination of these languages. The project doesn’t require too much prior knowledge of Paludis and should be reasonably easy.
Paludis is a multi-format package manager. So far we’ve mostly made use of this to deal with ‘special’ repository types like ‘unwritten’ and ‘unavailable’. It would be good to integrate native Ruby Gems (or CPAN, or CTAN, or CRAN, or Hackage – you can pretend this idea is about one of those instead if you prefer) support into Paludis and Exherbo.
Full package manager integration for Gems isn’t something that’s been done by anyone on a production scale before. The Gems people seem interested, though: http://www.rubygems.org/read/chapter/14#page62
Attempts have been made at integrating Gems support into Paludis in the past. The idea has been shown to be implementable and sound; the main stumbling blocks have been:
The Gems metadata YAML file isn’t valid YAML, and can only be parsed by one obscure, unmaintained parser. See http://ciaranm.wordpress.com/2009/03/01/yaml-sucks-gems-sucks-syck-sucks/ for details.
Gems external dependencies aren’t in any useful format. Although we can mostly get by by having the user work these out by hand where necessary, ideally we’d have some way of letting developers override these.
How to handle distribution integration. Previous attempts were targetting Gentoo, where making mass changes to everything with Gems dependencies wasn’t an option. With Exherbo such a mass change is reasonably easy – you’d have to work out what a Gems dependency would look like, but the mass changes can be carried out by our friendly gnomes.
Applicants will need a decent knowledge of C++.
Version formats are currently limited to a fairly strict set of rules. These are mostly historical things we’ve inherited from Gentoo. For example, 1.2-3, 1.2B and 1.2-alpha3 are not valid versions, but 1.2.3, 1.2b and 1.2_alpha3 are; if upstreams use the former, packages have to jump through silly hoops to work around it. There’s no particular reason to keep these limitations.
This project would consist of:
Identifying which restrictions can and should be dropped. http://lists.exherbo.org/pipermail/exherbo-dev/2009-February/000400.html is a starting point.
Identifying which restrictions need to be kept, and which upstreams we shouldn’t try to handle. Although technically we could deal with roman numerals, for example, it’d probably be silly to do so.
Working out a new set of rules, including ordering. (From a Paludis perspective, and for general sanity reasons, we have to be able to less-than compare any two arbitrary versions. If a < b and b < c, a < c must hold. Similarly, if a < b, ! b < a. It’s ok to have two different-but-equal versions – currently, 000 is equal to 0.)
Updating Paludis to handle these new versions. From a public API perspective, you would have to give VersionSpec’s constructor a new parameter that tells it which set of parsing rules to use. You would then need to update every caller to pass such a parameter (fortunately, the compiler will find everywhere that needs changing for you), which in turn would require extending the EAPI definitions (this is the easy part). You would also have to extend or rewrite the current version parser and comparison rules. And, of course, you would need lots of unit tests.
Updating the various Exherbo packages that you previously identified as using ‘wrong’ version names to use the new rules.
Applicants would need either a decent knowledge of C++, or a basic knowledge of C++ and a willingness to put up with grouchy programmers who like to yell “needs more unit tests!” and “not enough error checking!
Files installed by packages are merged to / (or a different ROOT). Paludis has a powerful and flexible merger framework.
One interesting extension is to make a merger that will, instead of copying files, create a tar file on the fly. This will help creating and handling binary packages.
The project can use libraries to create tar files or implement the required bits in Paludis itself.
Applicants will need some experience with C++.