Difference between revisions of "SBR600 Potential Projects"

From CDOT Wiki
Jump to: navigation, search
(→‎Package the Raspberry Pi firmware)
(→‎Infrastructure Projects)
 
(15 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
This is a list of potential projects related to the [[SBR600]] course that need people.
 
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 [[Winter 2012 SBR600 Participants|project table/participants page]].
+
'''Students''': Please select a project that you're interested in and add an entry to the [[Fall 2013 SBR600 Participants|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  [[User:Chris Tyler|Chris Tyler]]).
 
'''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  [[User:Chris Tyler|Chris Tyler]]).
Line 16: Line 16:
 
* Resources - An initial list of computer and information resources to get started on 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.
 
* 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.
 
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.
Line 30: Line 29:
 
= Raspberry Pi Fedora Remix Projects =
 
= Raspberry Pi Fedora Remix Projects =
  
−
== Package the Raspberry Pi firmware ==
+
== Update the raspberrypi-config package ==
  
−
The Raspberry Pi ships with some proprietary firmware used by the graphics processing unit (GPU). This firmware should be packaged within Fedora.
+
The raspberrypi-config package contains the default configuration files for Pidora. These files need to be updated to reflect new options available in the Raspberry Pi firmware, as well as options that are not commonly used and may conflict with common use-cases - for example, the current configuration files cause kernel start-up messages to be reported on the serial port. This is rarely used, any may cause conflicts with other devices connected to that port (e.g., LCD displays).
−
 
 
−
Expected outcome: a Fedora package containing the Raspberry Pi firmware.
 
  
 
Skills required: packaging
 
Skills required: packaging
Line 40: Line 37:
 
Maximum number of participants: 1
 
Maximum number of participants: 1
  
 +
Expected result: An updated, working raspberrypi-config package
  
−
= Project Name =
+
== Kernel Configuration Files ==
−
<!-- Replace "Project Name" with the actual name of the project in the line above. -->
 
  
−
== Project Description ==
+
The build process for the kernel uses a configuration file to control which kernel capabilities are built into the kernel itself, which are built as loadable modules, and which are not built. The Pidora kernel configuration file is a combination of the RaspberryPi default configuration file and the Fedora configuration file. This project involves reviewing the Pidora kernel configuration to optimize it for the widest possible range of use-cases while ensuring a fairly small kernel image size.
  
−
<!-- Description should be no longer than a paragraph.  Include links to any relevant on-line resources.  For example, [http://fedoraproject.org/wiki] or [http://developer.mozilla.org MDC]. -->
+
Skills required: kernel configuration/building, packaging
  
−
== Project Leader(s) ==
+
Maximum number of participants: 1
  
−
<!-- Name(s) of primary people working on the project.  If you want to join a project as leader, discuss with other leaders first.  Include links to personal pages within wiki and to blog sites. -->
+
Expected result: An improved kernel configuration in the raspberrypi-kernel package
  
−
== Project Contributor(s) ==
+
== Profile and Improve RPM and YUM performance on the Pi ==
  
−
<!-- Name(s) of people casually working on the project, or who have contributed significant help.  Include links to personal pages within wiki. Adding the names of your contributors here is a nice way to thank them.
+
RPM/YUM appear to perform slowly on the Pi -- which is appropriate, since the Pi has a slower processor and storage system than most modern PCs -- but the performance can probably be improved. This project involves profileing the RPM/YUM operations to determine which parts of the processing are slowest, and then examining how those parts work to see if any improvements in speed are possible.
  
−
NOTE: only Project Leader(s) should add names here.  You should not add your own name to the Contributor list. -->
+
Skills required: profiling, programming, packaging
  
−
== Project Details ==
+
Maximum number of participants: 1
  
−
<!-- Provides more depth than the Project Description.  This is the place for technical discussions, project specs, or other details.  If this gets very long, you might consider breaking this part into multiple pages and linking to them. -->
+
Expected result: Either a report proving that RPM/YUM are as fast as can be expected on the Pi, or changes to affected packages to improve performance
  
−
== Project Plan ==
+
== Internationalization Support in Firstboot for Pidora 19 ==
  
−
Tracking mechanism (bugzilla, trac, github, ...):
+
This project involves taking the Pidora 19 Firstboot package and internationalizing it (making it possible to use multiple language files with Firstboot). Note that Pidora 19 is expected to use a Fedora 18-style Firstboot system (as was used in Pidora 18) rather than the firstboot system used in Fedora 19 and higher.
  
−
Key contacts:
+
Skills required: python, i11n using gettext, packaging
−
<!-- Add links to any mentors or key participants in the community. -->
 
  
−
Goals for each release and plans for reaching those goals:
+
Maximum number of participants: 1
−
<!-- Note: each contributor is expected to have unique goals. These goals may be ''related'' to other students' work, but must be ''distinct'' and ''attainable'' regardless of the state of the other students' work. For example, under the umbrella of one project title, one student may work on packaging a piece of software and another may work on documentation, or one may work on solving one bug and another on solving another bug, but two students must not work on the same bug or depend on the other students' work in order to be able to complete their own project. -->
 
−
* 0.1
 
−
* 0.2
 
−
* 0.3
 
−
 
 
−
== Communication ==
 
−
 
 
−
=== Mailing Lists ===
 
−
<!-- Add any appropriate mailing lists to which you are subscribed (e.g., see http://lists.fedoraproject.org -->
 
−
 
 
−
=== Upsteam Wiki and Web ===
 
−
<!-- Links to upstream wiki/web pages -->
 
−
 
 
−
=== Links/Bugs/Tracking ===
 
−
<!-- Add a link to any page(s) related to your work, including the bug numbers (on bugzilla or trac) -->
 
−
 
 
−
=== Source Code Control ===
 
−
<!-- Add a link to source code URLs, including git/mercurial/svn/cvs repositories -->
 
−
 
 
−
=== Blogs ===
 
−
<!-- Links to the blogs of people involved, both inside and outside Seneca -->
 
−
 
 
−
==== Seneca Particpants ====
 
−
 
 
−
==== Non-Seneca Participants ====
 
−
<!-- Links to the blogs of any non-Seneca participants in this project -->
 
−
 
 
−
==== Planets ====
 
−
<!-- Links to any planets related to this project -->
 
−
 
 
−
== Project News ==
 
−
 
 
−
<!-- This is where a permanent record of your releases and updates will go.  In these you should discuss the status or your work, your interactions with other members of the community (e.g., Seneca and Mozilla), problems you have encountered, etc. -->
 
−
 
 
−
== 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).
+
Expected result: A version of firstboot and the firstboot modules that are fully internationalized
  
−
In order to create a standard RPM package file, Dracut (initramfs) will need to be properly supported.
+
== New Firstboot for Pidora 20 ==
  
−
Expected outcome: the Fedora kernel package generates a Raspberry Pi kernel binary RPM.
+
Firstboot on the Pi varies a bit from firstboot on PCs, because the software isn't installed onto storage in the same way as PCs. This project involves updating the Fedora 20 firstboot package to work with Pidora 20.
  
−
Skills required: packaging, kernel building
+
Skills required: python programming, packaging, testing
−
 
 
−
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
 
Maximum number of participants: 1
  
−
== Package the Raspberry Pi kernel utility ==
+
Expected result: A version of the Fedora 19 or Fedora 20 firstboot that works on the Pi and has full support for the Pidora options (such as rootfs resizing)
  
−
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.
+
== Compiler Flags on Pidora ==
  
−
Expected outcome: a Fedora package for the Raspberry Pi kernel utility.
+
We're not sure if the compiler flags being used for Pidora are optimal. This project involves building a number of packages with different combinations of compiler flags, observing the results (in terms of binary size and performance) and recommending the optimal set of flags.
  
−
Skills required: packaging
+
Skills required: building, benchmarking
  
 
Maximum number of participants: 1
 
Maximum number of participants: 1
  
−
== Modify Grubby to work with the Raspberry Pi kernel ==
+
Expected result: Modified RPM macros that include the optimal flags for Pidora
  
−
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.
+
== Avahi Configuration for Pidora ==
  
−
Expected outcome: patches for grubby submitted upstream; the ARM grubby package will correctly install the Raspi kernel.
+
Avahi (zeroconf) enables discovery of computers without DNS or IP numbers. This project involves configuring Avahi for use on the Pi, so that other computers can connect to it by name without DNS support. This configuration must then be packaged in such a way that it can be included in the Pidora composes without causing conflicts.
  
−
Skills required: packaging, scripting (bash and/or python), testing/QA
+
Skills required: testing, packaging
  
 
Maximum number of participants: 1
 
Maximum number of participants: 1
  
−
== Create the raspi-logos and raspi-fedora-remix-release-notes packages ==
+
Expected results: A configuration package that, when installed, will correctly set up Avahi for local discovery on the Pi
−
 
 
−
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.
 
  
−
Skills required: documentation writing, graphics, packaging
+
== Upstream the Pidora RPM Changes ==
  
−
Maximum number of people: 2 (logos, release notes)
+
There are some small changes to the RPM system that have been done for Pidora. These changes need to be included in the upstream version of RPM. This project involves working with upstream to ensure that these changes are in the correct format and included in subsequent releases of RPM.
  
−
== Systemd ==
+
Skills required: interpersonal skills - negotiation, patch creation, packaging
−
 
 
−
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
 
Maximum number of participants: 1
  
−
== Firstboot ==
+
Expected results: Pidora RPM changes will be upstreamed
  
−
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).
+
== Wayland ==
  
−
Expected outcome: changes for firstboot committed upstream, or a package that extends firstboot packaged in Fedora.
+
Fedora 20 includes support for the Wayland display system. The RaspberryPi foundation has been working on a Wayland implementation for the Pi. This project involves getting the two to work well together.
  
−
Skills required: scripting (python), packaging
+
Skills required: system administration, debugging, possibly some programming, packaging
  
−
Maximum number of participants: 1
+
Maximum number of participants: 2
  
−
== Package Scratch ==
+
Expected results: The Wayland snapshot in Fedora 20 will be usable on the Pi (Ideal: fully packaged; Acceptable: Instructions on how to set it up)
  
−
[http://scratch.mit.edu/ 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.
+
== Automate Pidora Kernel and Firmware Building ==
  
−
Expected outcome: a Fedora package of Scratch.
+
The Raspberry Pi Foundation maintains a kernel fork that is updated frequently. We would like to package kernel and firmware changes on a daily basis, and have these available in a testing repository so that anyone can use them. Periodically, we will select a kernel-firmware combination from this testing repository and make it available as the main Pidora kernel.
  
−
Skills required: packaging
+
Skills required: scripting (python and/or bash), packaging
  
 
Maximum number of participants: 1
 
Maximum number of participants: 1
  
−
== Package KidsRuby ==
+
Expected results: Raspberry Pi kernel and firmware updates will be included in a package in a testing repository through an automated (cron'd) process
  
−
[http://kidsruby.com/download KidsRuby] is an educational programming editor/IDE for Ruby, which should be packaged for Fedora.
+
== Change raspberrypi-vc Package to Build from Source ==
  
−
Expected outcome: a Fedora package of KidsRuby.
+
Originally, the VideoCore IV GPU on the Pi was used with proprietary libraries which were only available in compiled form, so the raspberrypi-vc package was originally set up to package prebuilt binaries and not build from source. The source code for these libraries is now available, and the raspberrypi-vc package should be changed to build from source (this will help with SELinux compatibility).
  
 
Skills required: packaging
 
Skills required: packaging
Line 209: Line 137:
 
Maximum number of participants: 1
 
Maximum number of participants: 1
  
−
== Create a SD Card Installation Tool ==
+
Expected result: A new version of the raspberrypi-vc package that build from source, is compatible with the current Pidora package, and can be easily updated/maintained
  
−
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.
+
== Write an Updated Boot Screen ==
  
−
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.
+
Pidora includes an OpenGL-powered boot screen, which uses the Raspberry Pi Fedora Remix logo. The current code does not use OpenGL very effectively.
  
−
'''Note:'''Maximum number of participants: 3
+
This package should be updated to use OpenGL better and to use the Pidora logo.
  
−
= Project Name =
+
Skills required: C programming, OpenGL programming, packaging
−
<!-- Replace "Project Name" with the actual name of the project in the line above. -->
 
  
−
== Project Description ==
+
Maximum number of participants: 1
  
−
<!-- Description should be no longer than a paragraph.  Include links to any relevant on-line resources.  For example, [http://fedoraproject.org/wiki] or [http://developer.mozilla.org MDC]. -->
+
Expected result: A visually appealing boot screen, packaged as a drop-in replacement for the current boot screen
  
−
== Project Leader(s) ==
+
== Update rootfs-resize ==
  
−
<!-- Name(s) of primary people working on the project. If you want to join a project as leader, discuss with other leaders first. Include links to personal pages within wiki and to blog sites. -->
+
The rootfs-resize package resizes the Pidora rootfs after installation. It works with primary partitions, and it works with the NOOBS system, but it doesn't work with a NOOBS-style layout outside of NOOBS (i.e., where the rootfs is placed in an extended partition). This project involves extending rootfs-resize so that it can resize extended and logical partitions as well as primary partitions.
  
−
== Project Contributor(s) ==
+
Skills required: Python scripting/programming, system administration, packaging
  
−
<!-- Name(s) of people casually working on the project, or who have contributed significant help.  Include links to personal pages within wiki. Adding the names of your contributors here is a nice way to thank them.
+
Maximum number of participants: 1
  
−
NOTE: only Project Leader(s) should add names here.  You should not add your own name to the Contributor list. -->
+
Expected result: An updated rootfs-resize package
  
−
== Project Details ==
+
== Packaging Pi-compatible Software ==
  
−
<!-- Provides more depth than the Project Description. This is the place for technical discussions, project specs, or other details.  If this gets very long, you might consider breaking this part into multiple pages and linking to them. -->
+
There are a number of Pi-specific software packages that could/should be included in Pidora. Select one, package it, and get it into Fedora (preferred) or directly into Pidora.
  
−
== Project Plan ==
+
{{Admon/tip|Finding Your Own Package|You can find any Pi-specific software and propose packaging it for your project. Note that it must be (a) broadly-useful Pi-specific software, or (b) a substantial software package that would be generally useful in Fedora and specifically on the Pi, in order to be approved as a project.}}
  
−
Tracking mechanism (bugzilla, trac, github, ...):
+
Some possible packages ideas to get you started:
 +
* Adafruit WebIDE
 +
* Adafruit libraries/tools/etc (select a specific piece of software)
 +
* OMXplayer
 +
* Vidcore library compatibility package (symlink farm in /opt/vc so that source code expecting to find the VC libraries there will work successfully)
 +
* Quick2wire python library
  
−
Key contacts:
+
See the [http://trac.proximity.on.ca/projects/rpfr/report/1 Pidora Bug Tracker] for ideas for other packages that people want included in Pidora.
−
<!-- Add links to any mentors or key participants in the community. -->
 
  
−
Goals for each release and plans for reaching those goals:
+
Skills required: packaging
−
<!-- Note: each contributor is expected to have unique goals. These goals may be ''related'' to other students' work, but must be ''distinct'' and ''attainable'' regardless of the state of the other students' work. For example, under the umbrella of one project title, one student may work on packaging a piece of software and another may work on documentation, or one may work on solving one bug and another on solving another bug, but two students must not work on the same bug or depend on the other students' work in order to be able to complete their own project. -->
 
−
* 0.1
 
−
* 0.2
 
−
* 0.3
 
  
−
== Communication ==
+
Maximum number of participants: 1 per package (identify the package!)
  
−
=== Mailing Lists ===
+
Expected result: A working, Pidora-compatible package that has gone through package review
−
<!-- Add any appropriate mailing lists to which you are subscribed (e.g., see http://lists.fedoraproject.org -->
 
  
−
=== Upsteam Wiki and Web ===
+
== Clean Up the Pidora Kickstart File ==
−
<!-- Links to upstream wiki/web pages -->
 
  
−
=== Links/Bugs/Tracking ===
+
The Pidora images are composed using a kickstart-based process. The kickstart file could be cleaned up for better readability and smallest-functional package selection.
−
<!-- Add a link to any page(s) related to your work, including the bug numbers (on bugzilla or trac) -->
 
  
−
=== Source Code Control ===
+
Recent (but not necessarily latest) kickstart: http://scotland.proximity.on.ca/raspberrypi/test-releases/rpfr18v6/latest/pidora-18.ks
−
<!-- Add a link to source code URLs, including git/mercurial/svn/cvs repositories -->
 
  
−
=== Blogs ===
+
Skills required: packaging, composing
−
<!-- Links to the blogs of people involved, both inside and outside Seneca -->
 
  
−
==== Seneca Particpants ====
+
Maximum number of participants: 1
  
−
==== Non-Seneca Participants ====
+
Expeccted result: A clean kickstart file for Pidora 19
−
<!-- Links to the blogs of any non-Seneca participants in this project -->
 
  
−
==== Planets ====
+
= Infrastructure Projects =
−
<!-- Links to any planets related to this project -->
 
  
−
== Project News ==
+
== Bug Tracker for Pidora ==
  
−
<!-- This is where a permanent record of your releases and updates will go. In these you should discuss the status or your work, your interactions with other members of the community (e.g., Seneca and Mozilla), problems you have encountered, etc. -->
+
Pidora currently uses a Trac instance for bug tracking. However, there is a lot of spammer activity on that system. Implement an effective spam prevention system on Trac, or implement an alternative bug tracking system such as Bugzilla. Document the solution for future maintainability.
  
−
== Create the F17 Raspberry Pi image ==
+
Skills required: system administration, documentation
  
−
Based on feedback on the F14 Raspberry Pi image, create an F17 alpha/beta image for the Raspberry Pi.
+
Maximum number of participants: 1
−
 
 
−
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.
+
Expected result: A spam-resistant bug tracking system
  
−
Skills required: system administration, scripting, testing/QA
+
== Create a Fedpkg-compatible Package Repository for Pidora ==
  
−
Maximum number of participants: 2 (scripting, testing)
+
Fedpkg is a tool used to manage Fedora packages using GIT (and http). We'd like to be able to use it for Pidora-specific (non-Fedora) packages as well. To set up Fedpkg, a package database (pkgdb), GIT repository, http repository, and Fedpg configuration will be required. Completion of the various components of this project should result in a usable, RPM-installable Fedpkg configuration for Pidora packages.
  
−
== Create the Raspi Repositories ==
+
Skills required: system administration, testing, packaging
  
−
Set up the repositories to distribute the F17 Raspberry Pi remix files, including:
+
Maximum number of participants: 3
−
* 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
+
Expected result: A working Fedpkg repository, plus configuration files packaged up in an RPM
  
−
Maximum number of participants: 1
+
== Mirrorlist CGI Script ==
  
−
= Fedora-ARM Projects =
+
Yum uses a mirrorlist retrieved from a server to determine which mirrors to use for downloading packages. This mirrorlist can be generated by a script (e.g., to randomize or to optimize mirror selection), but at the present time a static file is just passed through to the yum client.
  
−
== Set up a Koji Test Hub ==
+
Skills required: scripting, testing
−
 
 
−
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
 
Maximum number of participants: 1
  
−
== Document YUM Api ==
+
Expected result: An updated mirrorlist script
−
 
 
−
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
 

Latest revision as of 11:41, 25 September 2013


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.

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.

Important.png
Individual Deliverables
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

Update the raspberrypi-config package

The raspberrypi-config package contains the default configuration files for Pidora. These files need to be updated to reflect new options available in the Raspberry Pi firmware, as well as options that are not commonly used and may conflict with common use-cases - for example, the current configuration files cause kernel start-up messages to be reported on the serial port. This is rarely used, any may cause conflicts with other devices connected to that port (e.g., LCD displays).

Skills required: packaging

Maximum number of participants: 1

Expected result: An updated, working raspberrypi-config package

Kernel Configuration Files

The build process for the kernel uses a configuration file to control which kernel capabilities are built into the kernel itself, which are built as loadable modules, and which are not built. The Pidora kernel configuration file is a combination of the RaspberryPi default configuration file and the Fedora configuration file. This project involves reviewing the Pidora kernel configuration to optimize it for the widest possible range of use-cases while ensuring a fairly small kernel image size.

Skills required: kernel configuration/building, packaging

Maximum number of participants: 1

Expected result: An improved kernel configuration in the raspberrypi-kernel package

Profile and Improve RPM and YUM performance on the Pi

RPM/YUM appear to perform slowly on the Pi -- which is appropriate, since the Pi has a slower processor and storage system than most modern PCs -- but the performance can probably be improved. This project involves profileing the RPM/YUM operations to determine which parts of the processing are slowest, and then examining how those parts work to see if any improvements in speed are possible.

Skills required: profiling, programming, packaging

Maximum number of participants: 1

Expected result: Either a report proving that RPM/YUM are as fast as can be expected on the Pi, or changes to affected packages to improve performance

Internationalization Support in Firstboot for Pidora 19

This project involves taking the Pidora 19 Firstboot package and internationalizing it (making it possible to use multiple language files with Firstboot). Note that Pidora 19 is expected to use a Fedora 18-style Firstboot system (as was used in Pidora 18) rather than the firstboot system used in Fedora 19 and higher.

Skills required: python, i11n using gettext, packaging

Maximum number of participants: 1

Expected result: A version of firstboot and the firstboot modules that are fully internationalized

New Firstboot for Pidora 20

Firstboot on the Pi varies a bit from firstboot on PCs, because the software isn't installed onto storage in the same way as PCs. This project involves updating the Fedora 20 firstboot package to work with Pidora 20.

Skills required: python programming, packaging, testing

Maximum number of participants: 1

Expected result: A version of the Fedora 19 or Fedora 20 firstboot that works on the Pi and has full support for the Pidora options (such as rootfs resizing)

Compiler Flags on Pidora

We're not sure if the compiler flags being used for Pidora are optimal. This project involves building a number of packages with different combinations of compiler flags, observing the results (in terms of binary size and performance) and recommending the optimal set of flags.

Skills required: building, benchmarking

Maximum number of participants: 1

Expected result: Modified RPM macros that include the optimal flags for Pidora

Avahi Configuration for Pidora

Avahi (zeroconf) enables discovery of computers without DNS or IP numbers. This project involves configuring Avahi for use on the Pi, so that other computers can connect to it by name without DNS support. This configuration must then be packaged in such a way that it can be included in the Pidora composes without causing conflicts.

Skills required: testing, packaging

Maximum number of participants: 1

Expected results: A configuration package that, when installed, will correctly set up Avahi for local discovery on the Pi

Upstream the Pidora RPM Changes

There are some small changes to the RPM system that have been done for Pidora. These changes need to be included in the upstream version of RPM. This project involves working with upstream to ensure that these changes are in the correct format and included in subsequent releases of RPM.

Skills required: interpersonal skills - negotiation, patch creation, packaging

Maximum number of participants: 1

Expected results: Pidora RPM changes will be upstreamed

Wayland

Fedora 20 includes support for the Wayland display system. The RaspberryPi foundation has been working on a Wayland implementation for the Pi. This project involves getting the two to work well together.

Skills required: system administration, debugging, possibly some programming, packaging

Maximum number of participants: 2

Expected results: The Wayland snapshot in Fedora 20 will be usable on the Pi (Ideal: fully packaged; Acceptable: Instructions on how to set it up)

Automate Pidora Kernel and Firmware Building

The Raspberry Pi Foundation maintains a kernel fork that is updated frequently. We would like to package kernel and firmware changes on a daily basis, and have these available in a testing repository so that anyone can use them. Periodically, we will select a kernel-firmware combination from this testing repository and make it available as the main Pidora kernel.

Skills required: scripting (python and/or bash), packaging

Maximum number of participants: 1

Expected results: Raspberry Pi kernel and firmware updates will be included in a package in a testing repository through an automated (cron'd) process

Change raspberrypi-vc Package to Build from Source

Originally, the VideoCore IV GPU on the Pi was used with proprietary libraries which were only available in compiled form, so the raspberrypi-vc package was originally set up to package prebuilt binaries and not build from source. The source code for these libraries is now available, and the raspberrypi-vc package should be changed to build from source (this will help with SELinux compatibility).

Skills required: packaging

Maximum number of participants: 1

Expected result: A new version of the raspberrypi-vc package that build from source, is compatible with the current Pidora package, and can be easily updated/maintained

Write an Updated Boot Screen

Pidora includes an OpenGL-powered boot screen, which uses the Raspberry Pi Fedora Remix logo. The current code does not use OpenGL very effectively.

This package should be updated to use OpenGL better and to use the Pidora logo.

Skills required: C programming, OpenGL programming, packaging

Maximum number of participants: 1

Expected result: A visually appealing boot screen, packaged as a drop-in replacement for the current boot screen

Update rootfs-resize

The rootfs-resize package resizes the Pidora rootfs after installation. It works with primary partitions, and it works with the NOOBS system, but it doesn't work with a NOOBS-style layout outside of NOOBS (i.e., where the rootfs is placed in an extended partition). This project involves extending rootfs-resize so that it can resize extended and logical partitions as well as primary partitions.

Skills required: Python scripting/programming, system administration, packaging

Maximum number of participants: 1

Expected result: An updated rootfs-resize package

Packaging Pi-compatible Software

There are a number of Pi-specific software packages that could/should be included in Pidora. Select one, package it, and get it into Fedora (preferred) or directly into Pidora.

Idea.png
Finding Your Own Package
You can find any Pi-specific software and propose packaging it for your project. Note that it must be (a) broadly-useful Pi-specific software, or (b) a substantial software package that would be generally useful in Fedora and specifically on the Pi, in order to be approved as a project.

Some possible packages ideas to get you started:

  • Adafruit WebIDE
  • Adafruit libraries/tools/etc (select a specific piece of software)
  • OMXplayer
  • Vidcore library compatibility package (symlink farm in /opt/vc so that source code expecting to find the VC libraries there will work successfully)
  • Quick2wire python library

See the Pidora Bug Tracker for ideas for other packages that people want included in Pidora.

Skills required: packaging

Maximum number of participants: 1 per package (identify the package!)

Expected result: A working, Pidora-compatible package that has gone through package review

Clean Up the Pidora Kickstart File

The Pidora images are composed using a kickstart-based process. The kickstart file could be cleaned up for better readability and smallest-functional package selection.

Recent (but not necessarily latest) kickstart: http://scotland.proximity.on.ca/raspberrypi/test-releases/rpfr18v6/latest/pidora-18.ks

Skills required: packaging, composing

Maximum number of participants: 1

Expeccted result: A clean kickstart file for Pidora 19

Infrastructure Projects

Bug Tracker for Pidora

Pidora currently uses a Trac instance for bug tracking. However, there is a lot of spammer activity on that system. Implement an effective spam prevention system on Trac, or implement an alternative bug tracking system such as Bugzilla. Document the solution for future maintainability.

Skills required: system administration, documentation

Maximum number of participants: 1

Expected result: A spam-resistant bug tracking system

Create a Fedpkg-compatible Package Repository for Pidora

Fedpkg is a tool used to manage Fedora packages using GIT (and http). We'd like to be able to use it for Pidora-specific (non-Fedora) packages as well. To set up Fedpkg, a package database (pkgdb), GIT repository, http repository, and Fedpg configuration will be required. Completion of the various components of this project should result in a usable, RPM-installable Fedpkg configuration for Pidora packages.

Skills required: system administration, testing, packaging

Maximum number of participants: 3

Expected result: A working Fedpkg repository, plus configuration files packaged up in an RPM

Mirrorlist CGI Script

Yum uses a mirrorlist retrieved from a server to determine which mirrors to use for downloading packages. This mirrorlist can be generated by a script (e.g., to randomize or to optimize mirror selection), but at the present time a static file is just passed through to the yum client.

Skills required: scripting, testing

Maximum number of participants: 1

Expected result: An updated mirrorlist script

Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=SBR600_Potential_Projects&oldid=99381"