Please contact Bryan Østergaard at kloeri@exherbo.org or kloeri in the #exherbo channel on irc.freenode.net for further information if you’re interested in any of these projects.
Develop a client using 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.
Ali Polatel has written a REMOTE_IDS client that works with pypi, freshmeat, cpan, vim and rubyforge hosted projects. Possible ideas includes expanding the script to cover more hosting sites and using public APIs where possible.
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’ve added a basic raw image building script called create-kvm-image written in bash. It works for most basic cases but needs a lot more features. It should be relatively easy to add most of these features to the script.
Features wanted
Ability to specify filesystem types for each partitition. Right now it’s all hardcoded
Some way of specifying partition layout - the number of partitions, sizes of each and mount points
Allow the user to specify his own kernel configuration instead of the mostly defconfig derived hardcoded configuration
Possibly rewrite (parts of) the script using libguestfs. This would also allow us to relatively easy run commands in the guest image as part of build process
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 Popularity Contest and Ubuntu Popularity Contest 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.
Something like Gentoo Packages or Debian Packages.
Use the Paludis API (probably the Ruby or Python bindings, rather than the C++ API) to extract information about available packages, and present it in the form of a website.
You will want to consider:
Static vs dynamic generation. Is it easier to batch build static web pages for package information? What would the performance implications of doing everything dynamically be?
How should information be displayed? Is there a ‘one size fits all’ approach to formatting, or would users and developers be looking for different presentations or subsets of the data?
How can you make best use of the REMOTE_IDS metadata carried by packages? Can you make use of additional information supplied by some upstream hosting providers?
Prospective students should already be familiar with HTML, CSS and probably CGI, as well as one of Ruby, Python or C++.
SUMMER is Statically Updated Metadata Manifestation for Exherbo Repositories. It’s a crude ruby script accessible from http://summer.exherbo.org .
The wishlist of feature can be found in the README
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: RubyGems integration
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++.
Copyright 2009 Bryan Østergaard, Ciaran McCreesh and Fernando J. Pereda
This work is licensed under the Creative Commons Attribution Share Alike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/; or, (b) send a letter to Creative Commons, 171 2nd Street, Suite 300, San Francisco, California, 94105, USA.