Moblin/Build Service

From openSUSE

Revision as of 19:51, 30 June 2009

This article is a stub! This article needs to be expanded. You are welcome to help in line with the openSUSE Style Guide. See also the other articles that need to be expanded.

Moblin in the openSUSE Build Service

The openSUSE-based Moblin distribution is maintained entirely in the openSUSE.org Build Service. This allows users to build their own Moblin distribution using KIWI, or even just test-drive pieces of the Moblin UI on top of an existing stock openSUSE installation.

This document is intended primarily for developers interested in testing or contributing to openSUSE Moblin.

Moblin OBS Goals

• Follow the normal openSUSE workflow as closely as possible to minimize the learning curve for contributor involvement in openSUSE Moblin
• 100% of openSUSE Moblin work happens in the public openSUSE.org Build Service instance
  • openSUSE community members are always first-class citizens in the project with the ability to drive and mold the openSUSE Moblin initiative
  • Novell employees working on openSUSE Moblin use exactly the same public tools and workflow

OBS Projects

There are four primary OBS projects that define the openSUSE Moblin distribution. This includes two devel projects, an image project, and the factory aggregate project, all under the Moblin namespace:

Workflow Overview

As stated in Goals, the openSUSE Moblin project aims to be as familiar as possible for existing openSUSE contributors. First a quick overview of the workflow in openSUSE proper is offered, and then detailed is how this workflow is adapted for openSUSE Moblin.

openSUSE Base

In the regular openSUSE distribution, there is already a well-defined workflow that openSUSE Moblin uses and builds on. openSUSE contributors should have no problems contributing to openSUSE Moblin.

• Most packages are maintained in "devel projects" organized and maintained by teams with a certain interests, such as GNOME:Factory or Banshee
• Contributors (community members and Novell employees alike) branch packages from these projects to make and test their changes
• When the contributor is satisfied with changes, the package is submitreq'd (merged) to the devel project for acceptance by a maintainer of the project
• The package may ultimately then be submitreq'd to openSUSE:Factory for inclusion into the distribution

openSUSE Moblin

• As mentioned in OBS Projects, there are three new Moblin-specific devel projects in OBS
  • Moblin:Base
  • Moblin:UI
  • Moblin:Images
• Ideally we try to use as many packages from their proper devel projects, differing as little as possible
• Moblin:Base and Moblin:UI projects should contain as small a package set as possible
  • Reduces maintenance overhead
  • Causes less diversion from core openSUSE distribution
• Same workflow as openSUSE
  • For example: branch a package, hack on it, submitreq to Moblin:UI
  • If the change is stable, complete, and tested against Moblin:UI, then submitreq to Moblin:Factory

OBS Tools

The openSUSE Moblin project is relying on the latest tools for working with the openSUSE Build Service. The latest development version of the osc tool is required to build images.

You should subscribe to the openSUSE:Tools:Devel repository and install the latest osc-svn and build-svn packages (remove the osc and build packages if you have them installed already).

sudo zypper ar -f http://download.opensuse.org/repositories/openSUSE:/Tools:/Devel/openSUSE_11.1 openSUSE_Tools_Devel
sudo zypper remove osc build
sudo zypper install osc-svn build-svn

We are driving some changes into these tools as we work on Moblin, so there may be updates that will ease development (particularly with image building speed). Always ensure your tools are up to date.

Workflow Examples

Working on a Moblin-specific package

If you need to work on a package that is specific only to Moblin (e.g. it's not included in the core openSUSE distribution or canonically maintained in another devel project), then the workflow is simple:

1. Identify the package you wish to change, and branch it from the canonical devel project. Here we'll work on mutter-moblin in the Moblin:UI devel project.

   osc branch Moblin:UI mutter-moblin

2. Checkout the branched package

   osc co home:aaronbockover:branches:Moblin:UI/mutter-moblin

3. Change to the checkout directory and make and test your changes.

   cd $_

4. Once you have made your changes, you may either build the package locally with osc build or submit your changes to your branch on the server to build remotely:

   osc ci

5. Install and test your new package when it is finished building. If the change works as intended, properly document it in the .changes (create one if it doesn't exist), and submit the package for acceptance back into the canonical devel project.

   osc submitreq home:aaronbockover:branches:Moblin:UI mutter-moblin Moblin:UI \
       -m "Detail your change, mentioning why it should be accepted into the devel project"

6. A maintainer of the Moblin:UI project will be notified of your submission and will review it. It is very important that the message specified on the osc submitreq command be detailed and useful for review.

   When your package is accepted into the devel project, you will be notified by email. At that time, monitor the build status of the entire Moblin:UI tree to ensure that your change didn't inadvertently break the Moblin:UI tree.

   When the tree turns green again, a maintainer of Moblin:UI will forward the package to Moblin:Factory.

7. <p>When your change is checked in to Moblin:UI and forwarded to Moblin:Factory, you may delete the branch package. You'll need to delete it in case you re-branch the package at a future point in time.

   osc rdelete home:aaronbockover:branches:Moblin:UI mutter-moblin

Working on a package maintained in a non-Moblin canonical devel project

If you need to update a package in openSUSE Moblin that is part of the core openSUSE distribution or maintained in a non-Moblin devel project (e.g. taglib-sharp from Banshee), it is highly encouraged that your change be as thoughtful of the "upstream" as possible.

Minimizing incompatible changes is an extremely important goal as it helps reduce the maintenance overhead on the entire openSUSE Moblin distribution by diverging as little as possible.

If you make a change in such a package, you should coordinate with the upstream maintainers of the project, and the maintainer of the base openSUSE package.

For example, a change is needed to the hal package. hal is located in Moblin:Base, but is part of the base openSUSE distribution.