From Fedora Project Wiki

(→‎Packages in devel branch: update to use tools from fedora-packager)
(Update for modern day workings)
Line 37: Line 37:
 
</pre>
 
</pre>
  
* Use the command <code>make i386</code>, <code>make x86_64</code>, or <code>make ppc</code> to test a package build on your local system.  Then install and test the package.  If something doesn't work, fix it and repeat this step. You can also use the koji build system to do a scratch build perhaps for some arch you don't have locally: 'make srpm; koji build --scratch --arch-override x86_64 dist-f9 packagename-version-release.src.rpm' (to build just for x86_64 for example).
+
* Use the command <code>make i686</code> or <code>make x86_64</code> to test a package build on your local system.  Then install and test the package.  If something doesn't work, fix it and repeat this step. You can also use the koji build system to do a scratch build perhaps for some arch you don't have locally: 'make srpm; koji build --scratch --arch-override x86_64 dist-f14 packagename-version-release.src.rpm' (to build just for x86_64 for example).
  
 
* Check if everything that has changed is correct with
 
* Check if everything that has changed is correct with
Line 46: Line 46:
 
</pre>
 
</pre>
  
As a test whether the full commit was fine, you can check out a fresh working copy into a different directory. It should succeed in fetching the binaries from lookaside cache and also pass simple build tests such as '''make i386''' or '''make srpm''' at least.
+
As a test whether the full commit was fine, you can check out a fresh working copy into a different directory. It should succeed in fetching the binaries from lookaside cache and also pass simple build tests such as '''make i686''' or '''make srpm''' at least.
 
* Tag your package:
 
* Tag your package:
 
<pre>make tag
 
<pre>make tag
Line 54: Line 54:
 
</pre>
 
</pre>
 
* Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.
 
* Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.
* If you are updating a package during a freeze and need the package included in the milestone, please follow the [[Releases/Schedule| freeze policies]]  to have your package added.
 
  
 
=== Example ===
 
=== Example ===
Line 65: Line 64:
 
gedit foo.spec
 
gedit foo.spec
 
# change the required things in the specfile
 
# change the required things in the specfile
make i386
+
make i686
 
# check that the changes you made are correct
 
# check that the changes you made are correct
 
cvs diff -u
 
cvs diff -u
Line 74: Line 73:
 
</pre>
 
</pre>
  
The package builders publish your package in the <code>development</code> tree, also called "Rawhide."  If the package is a stable update, you may also provide it to users of the currently-maintained stable Fedora release.  To make it available to F-8 or F-9 users, for example, use the procedure outlined in the [[#Packages_in_the_stable_branches |next chapter]].
+
The package builders publish your package in the <code>development</code> tree, also called "Rawhide."  If the package is a stable update, you may also provide it to users of the currently-maintained stable, or branched Fedora release.  To make it available to F-11 or F-12 users, or testers of the branched F-13 for example, use the procedure outlined in the [[#Packages_in_the_stable_branches |next chapter]].
  
 
An alternative may be used, [[PackageMaintainers/UsingCvsFaq#Import_of_complete_src.rpm_packages| the import of a complete src.rpm]].
 
An alternative may be used, [[PackageMaintainers/UsingCvsFaq#Import_of_complete_src.rpm_packages| the import of a complete src.rpm]].
Line 81: Line 80:
 
[[PackageMaintainers/UsingKoji| UsingKoji]].
 
[[PackageMaintainers/UsingKoji| UsingKoji]].
  
=== Removing a package from the devel branch ===
+
=== Removing a package build from the devel branch ===
  
From time to time you may want to remove a package you pushed to the devel branch (rawhide).  This could happen in a situation where a bug
+
From time to time you may want to remove a package build you pushed to the devel branch (rawhide).  This could happen in a situation where a bug
 
or issue is found in your package that will be resolved upstream in upstream's next release.  You may want to wait for this release instead
 
or issue is found in your package that will be resolved upstream in upstream's next release.  You may want to wait for this release instead
 
of back-porting a fix yourself, and so pulling the broken package from rawhide makes sense.
 
of back-porting a fix yourself, and so pulling the broken package from rawhide makes sense.
 +
{{admon/caution|Use this carefully!|This should only be done on the same day of the build.  If your build has already been published in rawhide you must not untag it!}}
  
 
You can remove the package from rawhide by using koji as follows:
 
You can remove the package from rawhide by using koji as follows:
  
 
<pre>
 
<pre>
koji untag-pkg dist-f10 foo-1.1.3-1.fc10
+
koji untag-pkg dist-f13 foo-1.1.3-1.fc13
 
</pre>
 
</pre>
  
Where <code>foo-1.1.3-1.fc10</code> is replaced with the name of your package build.  See <code>koji help</code> or [[PackageMaintainers/UsingKoji | UsingKoji]] for more information.
+
Where <code>foo-1.1.3-1.fc13</code> is replaced with the name of your package build.  See <code>koji help</code> or [[PackageMaintainers/UsingKoji | UsingKoji]] for more information.
  
 
== Packages in the stable branches ==
 
== Packages in the stable branches ==
 +
Stable branches are branches within CVS for either released Fedoras, or a branched Fedora that is still in bugfix/polish mode but has not yet been released.
  
# Make any required changes in the <code>F-7</code>, <code>F-8/</code> or <code>F-9/</code> directory.  In many cases, you can apply the same changes from the <code>devel/</code> branch to the other branches.  Use the <code>diff</code> and <code>patch</code> utilities for this purpose.
+
# Make any required changes in the <code>F-11</code>, <code>F-12</code> or <code>F-13</code>, etc.. directory.  In many cases, you can apply the same changes from the <code>devel/</code> branch to the other branches.  Use the <code>diff</code> and <code>patch</code> utilities for this purpose.
# Use the command <code>make i386</code>, <code>make x86_64</code>, or <code>make ppc</code> to test a package build on your local system.  Then install and test the package.  If something doesn't work, fix it and repeat this step.
+
# Use the command <code>make i686</code> or <code>make x86_64</code> to test a package build on your local system.  Then install and test the package.  If something doesn't work, fix it and repeat this step.
 
# Commit the verified changes to the branch you are working on: <pre>cvs commit</pre>
 
# Commit the verified changes to the branch you are working on: <pre>cvs commit</pre>
 
# Tag your package: <pre>make tag</pre>
 
# Tag your package: <pre>make tag</pre>
Line 106: Line 107:
 
=== Submit your update to Bodhi ===
 
=== Submit your update to Bodhi ===
  
# This can be accomplished in a few different ways.  The easiest being: <pre>make update</pre>  If your local username differs from that of your Fedora account, you will need to specify it with the following command: <pre>make update BODHI_USER=foo</pre> Or you add <code>BODHI_USER=foo</code> to the file  <code>~/.cvspkgsrc</code>. Alternatively, you can also submit your update using the [https://fedorahosted.org/bodhi/wiki/CLI bodhi-client] , or the [https://admin.fedoraproject.org/updates web interface] .
+
# This can be accomplished in a few different ways.  The easiest being: <pre>make update</pre>  If your local username differs from that of your Fedora account, you will need to specify it with the following command: <pre>make update BODHI_USER=foo</pre> Or you add <code>BODHI_USER=foo</code> to the file  <code>~/.cvspkgsrc</code>.
# Once submitted, bodhi will automatically request that your update be pushed to updates-testing.  If you feel that community testing is unnecessary for your update, you can choose to push it straight to the stable fedora-updates repository instead. Note that security updates follow a [[Security/TrackingBugs |slightly different process]] .
+
## Alternatively, you can also submit your update using the [https://fedorahosted.org/bodhi/wiki/CLI bodhi-client]
 +
## or the [https://admin.fedoraproject.org/updates web interface] .
 +
# Once submitted, bodhi will automatically request that your update be pushed to updates-testing.  If you feel that community testing is unnecessary for your update, you can choose to push it straight to the stable fedora-updates repository instead. '''Pushing directly to stable skips peer review and is strongly discouraged!!''' Note that security updates follow a [[Security/TrackingBugs |slightly different process]] .
 
# A Release Engineer then signs and pushes out your updates.  The signing step is currently a manual process, so your updates will not be instantly released once submitted to bodhi.
 
# A Release Engineer then signs and pushes out your updates.  The signing step is currently a manual process, so your updates will not be instantly released once submitted to bodhi.
 
# Once pushed to testing, people are able to +1/-1 the updates "karma", based on whether or not it seems to be functional for them.  If your update reaches a karma of 3, it will automatically be pushed to stable.  Likewise, if it reaches -3, it will be automatically unpushed.  If your update does not receive enough feedback to automatically push it to stable, you will have to submit it as a final update yourself.  This can easily be done with the command-line tool, or with the web interface.
 
# Once pushed to testing, people are able to +1/-1 the updates "karma", based on whether or not it seems to be functional for them.  If your update reaches a karma of 3, it will automatically be pushed to stable.  Likewise, if it reaches -3, it will be automatically unpushed.  If your update does not receive enough feedback to automatically push it to stable, you will have to submit it as a final update yourself.  This can easily be done with the command-line tool, or with the web interface.

Revision as of 22:27, 16 February 2010

Fedora Package Update HOWTO

This document shows you how to update a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. For more information on becoming a package maintainer, refer to PackageMaintainers/Join. For more guidance on package updates, refer to PackageMaintainers/Package update guidelines. Use the procedure explained here to update your package.

Get Automatically Notified on New Upstream Releases

To automatically get notifications via bugzilla whenever upstream has a new release, refer to upstream release monitoring page.

Packages in devel branch

  • Check out your package from CVS.

Install fedora-packager if not already installed.

Check out a local working copy of the CVS module you plan to edit, e.g. (for a description of the directory layout, see the Anatomy page:

fedora-cvs <package_name>
  • If you update to a new upstream version you have to upload the tarball to an external lookaside cache. Operations on the lookaside cache require a client-side certificate, to get one run
    fedora-cert -n
    . To upload a new source tarball and replace an older one, run
make new-sources FILES="/path/to/yournewtarball.tar.gz"

You can omit the path if the source is the current directory.

In the branch directory (i.e. devel in this case) or for multiple files:

make new-sources FILES="yournewtarball.tar.gz yourdata.tar.gz"

This also updates your local copy of the .cvsignore and sources files. You will need to do this for each branch that you will be building the new version for. The new tarball will be uploaded only once and the rest will be md5sum checked and not uploaded, only the .cvsignore and sources files will be updated.

If you just want to add another tarball (e.g. a big gzipped patch or a documentation tarball), use:

make upload FILES="somefile.tar.gz"

Contrary to "make new-sources", this does not purge old files from the ".cvsignore" and "sources" files.

If you just have a small patch, initscript, or otherwise plain text file, you can commit those directly to CVS. This can be done with the cvs add command, e.g.:

cvs add packagename-fix-the-foobar.patch
  • Use the command make i686 or make x86_64 to test a package build on your local system. Then install and test the package. If something doesn't work, fix it and repeat this step. You can also use the koji build system to do a scratch build perhaps for some arch you don't have locally: 'make srpm; koji build --scratch --arch-override x86_64 dist-f14 packagename-version-release.src.rpm' (to build just for x86_64 for example).
  • Check if everything that has changed is correct with
cvs diff -u
  • Commit the verified changes to the devel/ branch.
cvs commit

As a test whether the full commit was fine, you can check out a fresh working copy into a different directory. It should succeed in fetching the binaries from lookaside cache and also pass simple build tests such as make i686 or make srpm at least.

  • Tag your package:
make tag
  • Instruct the builders to build your package:
make build

Example

fedora-cvs foo
cd foo/devel
wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2
make new-sources FILES="foo-0.0.2.tar.bz2"
gedit foo.spec
# change the required things in the specfile
make i686
# check that the changes you made are correct
cvs diff -u
# commit
cvs commit -m "Update to 0.0.2"
# request build
make tag build

The package builders publish your package in the development tree, also called "Rawhide." If the package is a stable update, you may also provide it to users of the currently-maintained stable, or branched Fedora release. To make it available to F-11 or F-12 users, or testers of the branched F-13 for example, use the procedure outlined in the next chapter.

An alternative may be used, the import of a complete src.rpm.

More in-depth information on the build system is at UsingKoji.

Removing a package build from the devel branch

From time to time you may want to remove a package build you pushed to the devel branch (rawhide). This could happen in a situation where a bug or issue is found in your package that will be resolved upstream in upstream's next release. You may want to wait for this release instead of back-porting a fix yourself, and so pulling the broken package from rawhide makes sense.

Stop (medium size).png
Use this carefully!
This should only be done on the same day of the build. If your build has already been published in rawhide you must not untag it!

You can remove the package from rawhide by using koji as follows:

koji untag-pkg dist-f13 foo-1.1.3-1.fc13

Where foo-1.1.3-1.fc13 is replaced with the name of your package build. See koji help or UsingKoji for more information.

Packages in the stable branches

Stable branches are branches within CVS for either released Fedoras, or a branched Fedora that is still in bugfix/polish mode but has not yet been released.

  1. Make any required changes in the F-11, F-12 or F-13, etc.. directory. In many cases, you can apply the same changes from the devel/ branch to the other branches. Use the diff and patch utilities for this purpose.
  2. Use the command make i686 or make x86_64 to test a package build on your local system. Then install and test the package. If something doesn't work, fix it and repeat this step.
  3. Commit the verified changes to the branch you are working on:
    cvs commit
  4. Tag your package:
    make tag
  5. Instruct the builders to build your package:
    make build
  6. Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.

Submit your update to Bodhi

  1. This can be accomplished in a few different ways. The easiest being:
    make update
    If your local username differs from that of your Fedora account, you will need to specify it with the following command:
    make update BODHI_USER=foo
    Or you add BODHI_USER=foo to the file ~/.cvspkgsrc.
    1. Alternatively, you can also submit your update using the bodhi-client
    2. or the web interface .
  2. Once submitted, bodhi will automatically request that your update be pushed to updates-testing. If you feel that community testing is unnecessary for your update, you can choose to push it straight to the stable fedora-updates repository instead. Pushing directly to stable skips peer review and is strongly discouraged!! Note that security updates follow a slightly different process .
  3. A Release Engineer then signs and pushes out your updates. The signing step is currently a manual process, so your updates will not be instantly released once submitted to bodhi.
  4. Once pushed to testing, people are able to +1/-1 the updates "karma", based on whether or not it seems to be functional for them. If your update reaches a karma of 3, it will automatically be pushed to stable. Likewise, if it reaches -3, it will be automatically unpushed. If your update does not receive enough feedback to automatically push it to stable, you will have to submit it as a final update yourself. This can easily be done with the command-line tool, or with the web interface.
  5. You will then be notified when your update has been pushed to stable. Bodhi will close all associated bugs and send an announcement to fedora-package-announce. At this point, your update has been officially released!

Reference

http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq