Difference between revisions of "SBR600 Potential Projects"

From CDOT Wiki
Jump to: navigation, search
(Infrastructure Projects)
 
(105 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[[Category:SBR600]]
+
[[Category:SBR600]][[Category:Winter 2012 SBR600]]
 +
 
 
= Introduction =
 
= Introduction =
  
 
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 [[Fall 2010 SBR600 Project Table|project table]].<!-- If you'd like to work on one of these, move the chosen project to the [[Project List]] and create a page for your work based on the Sample Project template. -->
+
'''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]]).
 +
 +
== Notes ==
 +
 +
Each project listing contains a general description, plus this information:
 +
* Maximum number of students - Do not exceed this number without approval from [[User:Chris Tyler|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.
 +
 +
{{Admon/important|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]] ==
 
== [[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 stubs below.  This is how you 'sign-up' for a 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).
  
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)''' page.  Otherwise, you can become a contributor later.
+
Skills required: packaging
  
= Fedora-ARM Projects =
+
Maximum number of participants: 1
  
== To Thumb or Not To Thumb? ==
+
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 core of all ARM processors are designs licensed from [http://www.arm.com ARM Ltd]. There are several different [[:fedora:ARM_architecture#ARM_cores|architecture versions]]; Fedora-ARM targets the armv5tel architecture as a "lowest common denominator" among current ARM chips. This architecture supports a ''thumb'' instruction set, which uses 16-bit instructions instead of 32-bit instructions, leading to a higher code density.
+
== Write an Updated Boot Screen ==
  
Fedora-ARM does not use thumb. The purpose of this project is to discover whether thumb provides any significant savings in terms of code size, whether programs compiled to thumb execute more quickly or more slowly than non-thumb programs on common ARM processors, whether a thumb compilation takes more or less time than non-thumb, and whether there are any other factors that would influence the decision to support thumb. Ultimately, this project should make a recommendation on the use of the thumb instruction set for the Fedora-ARM secondary architecture.
+
Pidora includes an OpenGL-powered boot screen, which uses the Raspberry Pi Fedora Remix logo. The current code does not use OpenGL very effectively.
  
Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
+
This package should be updated to use OpenGL better and to use the Pidora logo.
  
== Supporting Architectures Above armv5tel ==
+
Skills required: C programming, OpenGL programming, packaging
  
The armv5tel [[:fedora:ARM_architecture#ARM_cores|architecture version]] is supported by some common devices such as the Marvell Feroceon processors used in most plug computers. However, later versions of the architecture support advanced features, and using armv5tel code on those processors may result in suboptimal performance.
+
Maximum number of participants: 1
  
This project will research ways that Fedora-ARM could support higher processor versions effectively without recompiling the entire Fedora package universe -- for example, by providing an armv7 + hardfp glibc and kernel. This involves performance testing across multiple devices.
+
Expected result: A visually appealing boot screen, packaged as a drop-in replacement for the current boot screen
  
Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
+
== Update rootfs-resize ==
  
== Fedora-ARM Dogfood - Koji Hub ==
+
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.
  
The [http://arm.koji.fedoraproject.org Fedora-ARM koji] system uses [[CDOT_Development_Systems#Machine_names.2C_IPs.2C_and_Status|HongKong]], an x86_64 system, as the [[:fedora:Koji|Koji]] hub, along with a group of ARM builders.
+
Skills required: Python scripting/programming, system administration, packaging
  
Ideally, it would be nice to prove the ability of the Fedora-ARM project to be entirely self-hosting by using an ARM system as the Koji hub (this is sometimes called "Eating your own dogfood" in the industry). This project involves configuring the [http://www.globalscaletechnologies.com/t-openrdcdetails.aspx OpenRD-Client] system as Koji hub.
+
Maximum number of participants: 1
  
Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
+
Expected result: An updated rootfs-resize package
  
== Set up Nagios monitoring for the ARM farm ==
+
== Packaging Pi-compatible Software ==
Nagios is a system monitoring tool; setting it up for the Fedora-ARM build farm will make it easier to get timely notification of system issues.
 
  
Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
+
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.
  
== Set up Puppet ==
+
{{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.}}
Puppet is a tool for managing configuration files. It should be set up on the Fedora-ARM build farm so that configuration files can easily be deployed across the entire farm.
 
  
Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
+
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
  
== Set up FUNC ==
+
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.
Func is the Fedora Unified Network Controller -- a way of controlling a group of machines ''en masse''. We need FUNC set up for the Fedora-ARM build farm.
 
  
Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
+
Skills required: packaging
  
= Fedora Projects =
+
Maximum number of participants: 1 per package (identify the package!)
  
== fedpkg Test Suite ==
+
Expected result: A working, Pidora-compatible package that has gone through package review
  
''fedpkg'' is a new Fedora packager tool written by Jesse Keating; it's one of the main command-line tools that a packager will use. It needs a test suite, so that as new features are added, regressions can be detected.
+
== Clean Up the Pidora Kickstart File ==
  
Initial contacts: [http://jkeating.livejournal.com/ Oxf13]
+
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.
  
== Koji Setup Documentation ==
+
Recent (but not necessarily latest) kickstart: http://scotland.proximity.on.ca/raspberrypi/test-releases/rpfr18v6/latest/pidora-18.ks
  
Koji documentation is obsolete and needs a major overhaul. This project involves reading the current documentation, updating and editing it, and testing it by setting up a Koji system.
+
Skills required: packaging, composing
  
Initial contacts: [[User:Chris Tyler|ctyler]], dgilmore
+
Maximum number of participants: 1
  
== AutoQA ==
+
Expeccted result: A clean kickstart file for Pidora 19
[[:fedora:AutoQA|AutoQA]] is an automated test system for Fedora. At present there are event watchers for koji builds, bodhi updates, repo changes, and nightly installed images; these events trigger a small number of tests, but more tests are needed.
 
  
Initial contacts: [[:fedora:User:JLaska|JLaska]]
+
= Infrastructure Projects =
  
= Fedora-Mozilla Projects =
+
== Bug Tracker for Pidora ==
  
== Repository Setup for Mozilla Nightlies and Betas ==
+
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.
  
Many web developers want access to the latest Firefox pre-releases, including the nightly builds and beta releases. Mozilla's build team wants to make these accessible as parallel-installable binaries, released through a Fedora-compatible repository. This project involves setting this up.
+
Skills required: system administration, documentation
  
Subprojects:
+
Maximum number of participants: 1
* Build configuration for the RPM files.
 
* Repository configuration RPMs.
 
* Getting SELinux to work with the nightlies.
 
  
-> [https://bugzilla.mozilla.org/show_bug.cgi?id=600317 Bug 600317]<br />
+
Expected result: A spam-resistant bug tracking system
Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Armenzg|armenzg]]
 
  
= Mozilla Projects =
+
== Create a Fedpkg-compatible Package Repository for Pidora ==
  
== hgtools ==
+
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.
What if the Mozilla builders was better at managing all the different working directories (from Mercurial checkouts) we need at any give time? If you look at [https://bugzilla.mozilla.org/show_bug.cgi?id=589885#c11 this conversation from IRC] you can see the benefits of this and [https://bug506404.bugzilla.mozilla.org/attachment.cgi?id=476270 a patch] that has the initial work.
 
Initial contacts: [[User:Armenzg|Armenzg]]
 
  
== ScriptFactory ==
+
Skills required: system administration, testing, packaging
  
Imagine that we did not have to touch the Mozilla buildbot factories but instead we maintained a bunch of script for all the different jobs they run?
+
Maximum number of participants: 3
  
It would be good if we could create scripts that told a machine how to generate an optimized build, a debug build, unit tests, talos runs, locale repackages.
+
Expected result: A working Fedpkg repository, plus configuration files packaged up in an RPM
If you look in the [http://hg.mozilla.org/build/tools/file/tip/scripts tools/scripts] repo you can see that we have a simple shell file to do this for the fuzzing automation. The buildbot factory that calls it is called [http://hg.mozilla.org/build/buildbotcustom/file/a70b38b40088/process/factory.py#l7895 ScriptFactory] and it is very simple.
 
  
Initial contacts: [[User:Armenzg|Armenzg]]
+
== Mirrorlist CGI Script ==
  
== End-to-end project ==
+
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.
How can we build faster and provide tests results faster to our developers?
 
That is what we are trying to figure out and we will be adding bugs to this [https://bugzilla.mozilla.org/show_bug.cgi?id=598175 tracking bug] to optimize
 
our infrastructure.
 
  
Initial contacts: [[User:Armenzg|Armenzg]]
+
Skills required: scripting, testing
  
== I don't like waiting - give me a CPU! ==
+
Maximum number of participants: 1
We have a hundred jobs running per hour and we sometimes have jobs that have to wait for something before getting started. If we optimized the load we could use the build resources more effectively. I will be adding bugs to this [http://www.themoviemind.com/wp-content/uploads/2008/08/chuck-norris-2.jpg tracking bug] to reduce our load on our pools and therefore reduce our waiting times.
 
  
Initial contacts: [[User:Armenzg|Armenzg]]
+
Expected result: An updated mirrorlist script

Latest revision as of 10: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