SBR600 Potential Projects
It is still under construction and content may change. Do not rely on this information.
Introduction
This is a list of potential projects related to the SBR600 course that need people.
Students: Please select a project that you're interested in and add an entry to the project table/participants page.
Open Source Community Members: We welcome your recommendations for potential projects. Please create an account on this Wiki and create a description for your proposed project below. Please list your contact info (just an IRC or FAS2 name is OK) as well as links to any related web pages as Resources for the proposed project. (Questions? Ask Chris Tyler).
Notes
Each project listing contains a general description, plus this information:
- Maximum number of students - Do not exceed this number without approval from your professor.
- Skills required - This is a rough list of some of the skills required for this project. This list may be incomplete or inaccurate, but it will give you a starting point in evaluating whether this project is a good fit for you. It is not assumed that you will have all of these skills at the outset of the project -- some of them will be picked up as you do the project.
- Resources - An initial list of computer and information resources to get started on the project.
- Expected result - A rough indication of what is expected at the conclusion of the project.
- Initial contacts - Who to initially talk to about this project. These contacts may refer you on to other people with the respective open source communities.
You will have an opportunity to investigate, expand upon, and fine-tune this information as you prepare your initial project plan. For example, you may come up with a more detail list of expected results (deliverables), resources, and contacts during your planning.
Note that when multiple people are working on the same project, they will have independent deliverables -- it's not really group work, but rather separate, closely related projects.
Sample Project
This is a sample project stub. You can use the template for Sample Project in order to create a project page for one of the projects listed below. This is how you 'sign-up' for a project.
NOTE: if someone has already created the project page, speak to this person and see if you can join them. If so, simply add your name to the Project Leader(s) section on the project page. Otherwise, you can become a contributor later.
Raspberry Pi Fedora Remix Projects
Package the Raspberry Pi firmware
The Raspberry Pi ships with some proprietary firmware used by the graphics processing unit (GPU). This firmware should be packaged within Fedora.
Expected outcome: a Fedora package containing the Raspberry Pi firmware.
Skills required: packaging
Maximum number of participants: 1
Generate an RPM-based Raspberry Pi kernel
The Fedora project has a standard RPM kernel package. The Fedora ARM project has extended this package to build separate kernels for various ARM system-on-a-chip (SOC) platforms, generating binary RPM packages for kernel-omap, kernel-tegra, kernel-kirkwood, and so forth. This package should be extended to generate a kernel package for the Broadcom SOC used in the Raspberry Pi (either kernel-raspi or kernel-bcm).
In order to create a standard RPM package file, Dracut (initramfs) will need to be properly supported.
Expected outcome: the Fedora kernel package generates a Raspberry Pi kernel binary RPM.
Skills required: packaging, kernel building
Maximum number of participants: 2 (kernel package, initramfs/dracut setup)
Package the Raspberry Pi libraries
The Raspberry Pi includes a number of proprietary libraries. These libraries are expected to be re-licensed under an open source license in the coming months. These libraries should be packaged ready for inclusion in Fedora; until they are licensed under an open-source license, only the SRPMs should be released.
Note that the libray headers (-devel package) should be released in source form.
Expected outcome: a raspberrypi-firmware (or bcm2835-firmware) package containing the GPU firmware.
Skills required: packaging
Maximum number of participants: 1
Package the Raspberry Pi kernel utility
The Raspi bootloader requires a special header at the start of the kernel file in order to correctly load it into memory. The tool which creates this header needs to be packaged in Fedora.
Expected outcome: a Fedora package for the Raspberry Pi kernel utility.
Skills required: packaging
Maximum number of participants: 1
Modify Grubby to work with the Raspberry Pi kernel
On ARM systems, kernels are shipped as vmlinuz images (as on other platforms). The grubby utility is a tool which is used to configure the bootloader when a new kernel is installed, by adjusting the appropriate boot configuration (such as grub/grub2/lilo/elilo/...). On ARM systems, grubby generally calls mkimage to generate a uImage file from the vmlinuz file. On the Raspi, it will need to additionally call the Raspberry Pi kernel utility (described above) to convert the uImage into the kernel.img file.
Expected outcome: patches for grubby submitted upstream; the ARM grubby package will correctly install the Raspi kernel.
Skills required: packaging, scripting (bash and/or python)
Maximum number of participants: 1
Create the raspi-logos and raspi-fedora-remix-release-notes packages
Fedora usually contains three packages that cannot be redistributed with derived (remixed) versions:
- fedora-logos
- fedora-release
- fedora-release-notes
Dummy versions of these packages are available, substituting generic- for fedora- (i.e., generic-logos, generic-release, and generic-release-notes).
The fedora-release package has been replaced by the raspberrypi-fedora-remix-release package.
This project involves creating a replacement for the other two packages:
- raspberrypi-logos -- This package will contain replacements for the Fedora logos, including the Raspberry Pi logo (and possibly the Fedora secondary mark) where appropriate. It would probably also be a good idea to produce a raspberrypi-backgrounds package with Raspberry Pi-branded wallpaper.
- raspberrypi-fedora-remix-release-notes -- This package will contain documentation on the Remix, including notes on how to install it on an SD card, trademarks, use of the GPIO controls, etc.
Expected outcome: two packages.
Maximum number of people: 2 (logos, release notes)
Systemd
In Fedora 15 and later, the upstart startup system is replaced by systemd. Systemd needs to be tested on the Raspi, and as much as possible, tuned to use as little memory as possible.
Expected outcome: systemd is tested and ready for use on the Raspi in F17.
Skills required: debugging, sysadmin problem solving, testing/QA
Maximum number of participants: 1
Firstboot
The firstboot package asks the user specific questions when the system starts for the first time. Since Raspberry Pi systems are installed by copying the SD card, additional questions should be asked during the first boot -- for example, the root password and timezone should be set. This project involves writing and packaging additional modules for firstboot for use with the Raspi (and potentially other ARM systems).
Expected outcome: changes for firstboot committed upstream, or a package that extends firstboot packaged in Fedora.
Skills required: scripting (python), packaging
Maximum number of participants: 1
Package Scratch
Scratch is an educational programming environment from MIT. It's not licensed under an OSI-approved license, but the upstream project has indicated a willingness to relicense it. An OSI-approved license should be negotiated, and the software packaged for Fedora.
Expected outcome: a Fedora package of Scratch.
Skills required: packaging
Maximum number of participants: 1
Package KidsRuby
KidsRuby is an educational programming editor/IDE for Ruby, which should be packaged for Fedora.
Expected outcome: a Fedora package of KidsRuby.
Skills required: packaging
Maximum number of participants: 1
Create a SD Card Installation Tool
The Fedora LiveUSB-Creator tool can run on a Fedora or on a Windows system and can be used to download and install a Fedora live disc image on a USB flash drive. This tool should be adapted so that it can also create an SD card for the Raspberry Pi (and hopefully other devices) -- so that a user can install the Raspberry Pi remix without using commands such as fdisk, dd, and resize2fs.
Note: the liveusb-creator tool goes through a number of setup steps that are not required for an SD card. On the other hand, creating an SD card involves a few steps that are not necessary for a live USB. Therefore it might be appropriate to create a separate tool rather than modifying the liveusb-creator tool. Also, there are other efforts taking place within the Raspberry Pi community which might do the same thing; if one of those efforts reaches a stable release, it might be possible to package that for Fedora.
Expected outcome: a Fedora package of a tool to install the Raspi distribution image on an SD card. Ideally, a Windows version as well.
Skills required: scripting (python), system administration, testing/QA
Maximum number of participants: 3 (scripting, Fedora packaging and testing, Windows packaging and testing)
Create the F17 Raspberry Pi image
Based on feedback on the F14 Raspberry Pi image, create an F17 alpha/beta image for the Raspberry Pi.
This will involve modifying (or creating) a script to produce the Raspi rootfs, putting the rootfs and image into the final format for distribution.
Note: the final version of F17 won't be ready until just after this course ends. The image will need to be based on the F17 alpha/beta package set.
Expected outcome: a F17 image creation script.
Skills required: system administration, scripting, testing/QA
Maximum number of participants: 2 (scripting, testing)
Create the Raspi Repositories
Set up the repositories to distribute the F17 Raspberry Pi remix files, including:
- Setting up the signing keys
- Creating a standard signing procedure (SOP) for signing
- Creating a 'release' package containing the public keys and repo files
Expected outcome: repos, release package, SOP
Maximum number of participants: 1
Fedora-ARM Projects
Set up a Koji Test Hub
We have a Koji Hub to run the Fedora ARM build farm. However, we should have a separate hub for testing configurations before deploying them to the production server. This project involves setting up a test hub so that koji hub/builder configurations can be tested independently from the production server.
Expected outcome: a koji test server set up on England
Skills required: system administration
Maximum number of participants: 1
Document YUM Api
Yum is written in Python, but the yum API is poorly documented: the usual answer to a question about the API is: "ask Seth Vidal".
This is a hard project. Do not take it on unless you are really willing to complete this task.
Expected outcome: a guide to the yum API.
Skills required: investigation, scripting (python), writing
Maximum number of participants: 2