Developer/Fedora: Difference between revisions

From OLPC
Jump to navigation Jump to search
(→‎Placing a Package into a Build Stream: transcribe dennis' notes about maintaining forks)
(Added translation templates)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Developers}}
{{Translations}}

== Introduction ==
== Introduction ==


OLPC maintains a variant of the Fedora Linux distribution. Many developers, over the course of their careers developing for the XO, develop a need to package software for the XO, either because they wish to fix a bug in software contained in an existing package or because they wish to contribute new software (other than activities) to the system. This document is intended to explain how to package bug fixes for OLPC system software that is maintained in Fedora. Other documents, such as [http://fedoraproject.org/wiki/PackageMaintainers/Join] discuss the less common case of adding entirely new pieces of software to Fedora and of adding new activities, which are not currently maintained in Fedora.
OLPC maintains a variant of the Fedora Linux distribution. Many developers, over the course of their careers developing for the XO, develop a need to package software for the XO, either because they wish to fix a bug in software contained in an existing package or because they wish to contribute new software (other than activities) to the system. We do this through packaging the software in the upstream Fedora community, a process which this page aims to introduce.

There are two broad kinds of work that must be done to be able to take responsibility for maintaining an OLPC fork of a Fedora package - requesting authority to maintain a Fedora package and learning how to maintain a Fedora package. Fortunately, these tasks can be performed in parallel.




== Terminology ==
== Terminology ==
Line 29: Line 28:
;packaged software
;packaged software
: is the 'binary object' of a software distribution much as '.o' files are the binary objects linked together to produce C binaries
: is the 'binary object' of a software distribution much as '.o' files are the binary objects linked together to produce C binaries




== Outside Reading ==
== Outside Reading ==
Line 37: Line 34:


=== Fedora Procedures ===
=== Fedora Procedures ===
* http://fedoraproject.org/wiki/Join_the_package_collection_maintainers - '' Join the package collection maintainers''
* https://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo - ''How to update packages maintained in Fedora''
* https://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo - ''How to update packages maintained in Fedora''
* https://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq - ''How to access source code for packages maintained in Fedora''
* https://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq - ''How to access source code for packages maintained in Fedora''
Line 53: Line 51:
* https://admin.fedoraproject.org/pkgdb/ - ''Website for managing authorization to update Fedora packages''
* https://admin.fedoraproject.org/pkgdb/ - ''Website for managing authorization to update Fedora packages''
* http://koji.fedoraproject.org/koji/ - ''Status website for the Fedora build system''
* http://koji.fedoraproject.org/koji/ - ''Status website for the Fedora build system''



== Requesting Authority to Help Maintain an Existing Package or Branch of a Package ==

First and most important - if you get confused, '''ask for help!''' (Then help improve this page!)

Next, let's assume that you've demonstrated the interest and ability required to help to maintain an OLPC branch of a Fedora package. I'll use the OLPC branch of ''xkeyboard-config'' as a running example. Then, you might:
# Request a [https://bugzilla.redhat.com/ RedHat Bugzilla] account
#* RedHat and Fedora use Bugzilla extensively to keep track of administrative tasks relating to package maintenance.
# Request a Fedora account
#* Just follow the [http://fedoraproject.org/wiki/PackageMaintainers/Join#head-a601c13b0950a89568deafa65f505b4b58ee869b 'Get a Fedora Account'] instructions to access the [https://admin.fedoraproject.org/accounts/ Fedora Account System] (FAS2).
# Request membership in the fedorabugs and cvsextras groups through FAS2.
#* Just follow these [http://fedoraproject.org/wiki/PackageMaintainers/Join#head-a601c13b0950a89568deafa65f505b4b58ee869b instructions]
# Ask a Fedora Package Maintainer (such as dgilmore) to sponsor you.
# Use your Fedora account to request authority to update the OLPC branch of the package you want to fix.
#* Login to [https://admin.fedoraproject.org/pkgdb/ Fedora Package Database]
#* Navigate to the page for your package, e.g. [https://admin.fedoraproject.org/pkgdb/packages/name/xkeyboard-config#FedoraOLPC2 the dist-olpc2 branch of xkeyboard-config]
#* Request ACL entries to update the OLPC branch of the package you want to fix.



== Learning How to Maintain a Package ==

# Request an account on teach.laptop.org, install Fedora yourself, or install appropriate packages (rpmbuild, rpmdevtools, mock, and koji) if your distribution offers recent versions;
# Anonymously check out your package from [https://fedoraproject.org/wiki/UsingCvs Fedora CVS] <pre>CVSROOT=:pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs</pre><pre>cvs co <module></pre>
# Use mock or rpmbuild to learn how to build your package <pre>cd <module>/OLPC-2</pre><pre>make mockbuild MOCKCFG=fedora-7-i386</pre>
# [Politely] Seek help from OLPC and Fedora developers as you discover confusions.



== Placing a Package into a Build Stream ==

Once you've managed to modify your chosen package and to produce mock-built RPMs which satisfy you, then it's time to make your modifications available to the wider OLPC world. To do this, you need to insert your packages into an OLPC buildstream, either by (recommended) [http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo building and tagging them] in Fedora's [http://koji.fedoraproject.org/koji Koji] package maintenance system or (cheap-skates) by placing them in an appropriate [[Build system|dropbox]] on dev.laptop.org. The exact tags or stream-names you should use will vary over time and depending on the specific nature of your work. Ask on OLPC's development [[IRC#IRC|IRC channels]] for the most up-to-date information. After you have completed one of these steps, then your package can be included in an OLPC build. Depending on the exact build stream you're working in, this may occur automatically or you may be required to negotiate with your build stream's maintainer.

== Notes on forking packages for OLPC ==
Transcribed directly from Dennis Gilmore (dgilmore) on IRC for now; clean up welcome!
<pre>
you to get something branched for OLPC-3 you need to make a request in bugzilla.redhat.com
on the review bug. i suggest that you try contact the package maintainer first. they may be
willing to maintain for OLPC, they also may have other ideas on how to fix the issue that is
being seen. eliminating the need for a branch.

there is a bot in #fedora-devel called zodbot it will tell you who owns the package. or you
can look in pkgdb

zodbot has a fas commant that will give you contact details given a username

dgilmore: do you have a package w/ upstreamed olpc-specific changes that's a good template to
look at?

ntp was repackaged because of olpc

(02:20:43 PM) dgilmore: cscott: there are different senarios that warrant different actions
</pre>


[[Category:Developers]]
[[Category:Developers]]
[[Category:Software development]]
[[Category:XO software and Fedora]]

Latest revision as of 04:58, 22 May 2011

  For Developers
  Please copy/paste "{{Translationlist | xx | origlang=en | translated={{{translated}}}}}" (where xx is ISO 639 language code for your translation) to Developer/Fedora/translations HowTo [ID# 256300]  +/-  


Introduction

OLPC maintains a variant of the Fedora Linux distribution. Many developers, over the course of their careers developing for the XO, develop a need to package software for the XO, either because they wish to fix a bug in software contained in an existing package or because they wish to contribute new software (other than activities) to the system. We do this through packaging the software in the upstream Fedora community, a process which this page aims to introduce.

Terminology

upstream authors
are people who release source code for consumption by package maintainers and who accept or reject patches from interested individuals
package maintainers
are people who accept source code releases from upstream authors and who combine that source code with packaging instructions in order to produce packaged software
package maintainers are also responsible for contributing patches to upstream authors that fix bugs or that make the upstream software inter-operate more smoothly with other software
Frequently in OLPC, package maintainers and upstream authors are the same person.
source releases
are typically tarballs of source code that have been permanently published at a fixed URL, along with validation data such as MD5sums or the author's public key and a digital signature.
(it's important for many reasons that source code be permanently accessible for all packages. Please make sure that yours is.)
packaging instructions
consist of a '.spec' file and zero or more patches to a source release.
packaged source code
is the 'source object' of a software distribution much as '.c' and '.h' files are the units of source code for building C binary objects.
packaged software
is the 'binary object' of a software distribution much as '.o' files are the binary objects linked together to produce C binaries

Outside Reading

Here is a collection of sites that I have found useful in learning to maintain Fedora packages for OLPC:

Fedora Procedures

RPM Hints

Making or Modifying RPMS

Fedora Infrastructure

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Developer/Fedora&oldid=256300"