Package update HOWTO

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (Working with packages in the stable branches: use {{FedoraVersion|long|current}} and {{command|...}})
(36 intermediate revisions by 18 users not shown)
Line 1: Line 1:
{{Draft|This page is under re-construction. It covers NFR only for developer Users. To complete for Tester, Mirror, & Other}}
+
{{autolang|base=yes}}
 +
{{admon/note Run git config --global --add push.default tracking which instructs git to "push" to whatever branch you are tracking }}
  
 
This document shows how to update a package you maintain in Fedora.  It assumes you already have a package in the Fedora repositories.
 
This document shows how to update a package you maintain in Fedora.  It assumes you already have a package in the Fedora repositories.
 +
 
This document is divided in three sections to give Developers, Testers, and Mirror Admins some guidelines on how to submit packages for [[Releases/Rawhide | <code>rawhide]], development</code> and <code>pending</code>.  
 
This document is divided in three sections to give Developers, Testers, and Mirror Admins some guidelines on how to submit packages for [[Releases/Rawhide | <code>rawhide]], development</code> and <code>pending</code>.  
  
* For more information on becoming a package maintainer, refer to [[PackageMaintainers/Join]]
+
* For more guidance on package updates, refer to [[Updates_Policy]].
* For more guidance on package updates, refer to [[PackageMaintainers/Package update guidelines]].
+
  
 
== Overview ==
 
== Overview ==
Here you can find some preliminary information about the new process of Package Management. If you want to know the difference between [[Releases/Rawhide | <code>rawhide]], development</code> and <code>pending</code> , and which one is suitable for you, along with an overall understanding of the release naming and repos, visit our new and improved [[ReleaseEngineering/Overview | Fedora Development Process Overview]] page.  
+
 
 +
Here you can find detailed information on process of Package Management in Fedora. If you want to know the difference between [[Releases/Rawhide | <code>rawhide]], development</code> and <code>pending</code> , and which one is suitable for you, along with an overall understanding of the release naming and repos, visit our new and improved [[ReleaseEngineering/Overview | Fedora Development Process Overview]] page.  
  
 
New contributors (mandatory reading), new Testers (highly suggested reading), new Consumers (useful reading), or anybody interested in how Fedora is developed would find this page useful.
 
New contributors (mandatory reading), new Testers (highly suggested reading), new Consumers (useful reading), or anybody interested in how Fedora is developed would find this page useful.
  
 
In particular, these are the '''new paths on mirrors''':
 
In particular, these are the '''new paths on mirrors''':
* <code> /pub/fedora/linux/development/rawhide/ </code> will become the new path of Rawhide. It will continue to not have install images, and will be the place where builds from the <code> "devel" </code> branch in CVS go to. It'll be {{FedoraVersion|long|next}} intended content.
+
* <code> /pub/fedora/linux/development/rawhide/ </code> will become the new path of Rawhide. It will continue to not have install images, and will be the place where builds from the <code> "devel" </code> branch in git go to. It'll be {{FedoraVersion|long|next}} intended content.
* <code> /pub/fedora/linux/development/13/ </code> will become the new path of the branched Fedora 13 content. This is where builds from the F-13/ branch in CVS will go after they pass through Bodhi as "stable".
+
* <code> /pub/fedora/linux/development/{{FedoraVersion}} </code> will become the new path of the branched Fedora {{FedoraVersion}} content. This is where builds from the F-{{FedoraVersion}}/ branch in git will go after they pass through Bodhi as "stable".
* <code> /pub/fedora/linux/updates/testing/13/ </code> will be where potential Fedora 13 builds go after passing through bodhi as "testing". This is where you'll find the latest stuff proposed for ''freeze break'' and where testing and peer review of these freeze breaks will happen. When a maintainer feels enough testing has happened, or enough karma triggers the Bodhi auto request, the build will be marked "stable" and show up in the development/13 tree at the next nightly compose.  
+
* <code> /pub/fedora/linux/updates/testing/{{FedoraVersion}}/ </code> will be where potential Fedora {{FedoraVersion}} builds go after passing through bodhi as "testing". This is where you'll find the latest stuff proposed for ''freeze break'' and where testing and peer review of these freeze breaks will happen. When a maintainer feels enough testing has happened, or enough karma triggers the Bodhi auto request, the build will be marked "stable" and show up in the development/{{FedoraVersion}} tree at the next nightly compose.  
 +
 
 
(View [[No_Frozen_Rawhide_coming_soon | NFR coming soon! New paths on mirrors!]])
 
(View [[No_Frozen_Rawhide_coming_soon | NFR coming soon! New paths on mirrors!]])
  
 
== For Developers ==
 
== For Developers ==
{{admon/warning | This table is still under construction. Do not rely on it yet.}}
+
 
 
{{admon/note|
 
{{admon/note|
 
If you want to build a new package, but you aren't sure if it should go to Rawhide or {{FedoraVersion|long|next}}, then:
 
If you want to build a new package, but you aren't sure if it should go to Rawhide or {{FedoraVersion|long|next}}, then:
Line 71: Line 74:
 
|  
 
|  
 
|  
 
|  
|style="background-color:#DEF3FE" align=center| X<ref name="1">Mutually exclusive.</ref>   
+
|style="background-color:#DEF3FE" align=center| X<ref name="ref1">Mutually exclusive.</ref>   
 
|   
 
|   
|style="background-color:#DEF3FE" align=center| X<ref name="1">Mutually exclusive.</ref>
+
|style="background-color:#DEF3FE" align=center| X<ref name="ref1">Mutually exclusive.</ref>
 
|-
 
|-
 
|style="background-color:#DDDDDD"| For a package, in critical path, in the "pending" updates-testing repo for a week that hasn't received karma feedback  
 
|style="background-color:#DDDDDD"| For a package, in critical path, in the "pending" updates-testing repo for a week that hasn't received karma feedback  
Line 80: Line 83:
 
|  
 
|  
 
|   
 
|   
|style="background-color:#DEF3FE" align=center| X<ref name="2">Query [[QA|QA]]/[[ReleaseEngineering|Release Engineering]], too</ref>   
+
|style="background-color:#DEF3FE" align=center| X<ref name="ref2">Query [[QA|QA]]/[[ReleaseEngineering|Release Engineering]], too</ref>   
 
|  
 
|  
 
|-
 
|-
Line 97: Line 100:
 
|   
 
|   
 
|   
 
|   
|style="background-color:#DEF3FE" align=center| X<ref name="3">Provided the package has net positive Karma from QA or releng and at least one more net positive karma point. If karma autopush is checked submit to stable is done automatically</ref>
+
|style="background-color:#DEF3FE" align=center| X<ref name="ref3">Provided the package has net positive Karma from QA or releng and at least one more net positive karma point. If karma autopush is checked submit to stable is done automatically</ref>
 
|-
 
|-
|style="background-color:#DDDDDD"| To push a package built to handle an urgent issue (e.g. security problem, non-functioning system, etc.)  to the {{FedoraVersion|short|next}} branch <ref name="4">In all cases, it's ''necessary''  to be very very very sure the update will not cause additional problems'''</ref>
+
|style="background-color:#DDDDDD"| To push a package built to handle an urgent issue (e.g. security problem, non-functioning system, etc.)  to the {{FedoraVersion|short|next}} branch <ref name="ref4">In all cases, it's ''necessary''  to be very very very sure the update will not cause additional problems'''</ref>
 
|  
 
|  
 
|  
 
|  
Line 105: Line 108:
 
|   
 
|   
 
|   
 
|   
|style="background-color:#DEF3FE" align=center|  X<ref name="5">If the package is not in the critical path, nor addressing a security problem, then it can be requested a push to stable<BR>
+
|style="background-color:#DEF3FE" align=center|  X<ref name="ref5">If the package is not in the critical path, nor addressing a security problem, then it can be requested a push to stable<BR>
 
If the package addresses a security issue then it should be marked as security. Wait for the Security team to sign off on the update (not sure how this happens right now) before requesting the package be pushed to stable<BR>
 
If the package addresses a security issue then it should be marked as security. Wait for the Security team to sign off on the update (not sure how this happens right now) before requesting the package be pushed to stable<BR>
 
If the package is in the critical path, then wait for a QA/Release Engineering/Peer net positive karma vote in Bodhi before requesting the package be pushed to stable</ref>
 
If the package is in the critical path, then wait for a QA/Release Engineering/Peer net positive karma vote in Bodhi before requesting the package be pushed to stable</ref>
Line 126: Line 129:
  
 
{{admon/tip|  
 
{{admon/tip|  
To check and see if the build will be in the {{FedoraVersion|long|next}}, as they will be tagged with ''"dist-f1?"'', you can run ''koji latest-pkg dist-f1?'' to see what the latest build of your package is for {{FedoraVersion|long|next}}.}}
+
To check and see if the build will be in the {{FedoraVersion|long|next}}, as they will be tagged with ''"f1?"'', you can run ''koji latest-pkg f1?'' to see what the latest build of your package is for {{FedoraVersion|long|next}}.}}
 
<BR>
 
<BR>
  
Line 161: Line 164:
  
 
== Build a package for Rawhide ==
 
== Build a package for Rawhide ==
To build a package for Rawhide, check it out from the CVS devel/branch.
+
To build a package for Rawhide, check it out from the git devel/branch.
  
 
Install fedora-packager if not already installed.
 
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 [[PackageMaintainers/Anatomy| Anatomy]]  page:
+
Check out a local working copy of the git module you plan to edit, e.g. (for a description of the directory layout, see the [[PackageMaintainers/Anatomy| Anatomy]]  page:
<pre>fedora-cvs <package_name>
+
<pre>fedpkg clone <package_name>
 
</pre>
 
</pre>
 +
 +
{{Admon/important| Note: If you are not a member of the fedora packager group, you will receive a "permission denied" error.  Use the -a flag to clone anonymously. }}
 +
 +
{{Admon/important| Note: If you you use a separate ssh key for FAS, remember to load it into your ssh-agent. }}
  
 
* 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
 
* 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
Line 175: Line 182:
 
To upload a new source tarball and replace an older one, run
 
To upload a new source tarball and replace an older one, run
  
<pre>make new-sources FILES="/path/to/yournewtarball.tar.gz"
+
<pre>fedpkg new-sources /path/to/yournewtarball.tar.gz
 
</pre>
 
</pre>
  
Line 181: Line 188:
  
 
In the branch directory (i.e. devel in this case) or for multiple files:
 
In the branch directory (i.e. devel in this case) or for multiple files:
<pre>make new-sources FILES="yournewtarball.tar.gz yourdata.tar.gz"
+
<pre>fedpkg new-sources yournewtarball.tar.gz yourdata.tar.gz
 
</pre>
 
</pre>
  
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.
+
This also updates your local copy of the '''.gitignore''' 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 '''.gitignore''' 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:
 
If you just want to add another tarball (e.g. a big gzipped patch or a documentation tarball), use:
<pre>make upload FILES="somefile.tar.gz"
+
<pre>fedpkg upload somefile.tar.gz
 
</pre>
 
</pre>
Contrary to <code>make new-sources</code>, this does not purge old files from the <code>.cvsignore</code> and <code>sources</code> files.
+
Contrary to <code>fedpkg new-sources</code>, this does not purge old files from the <code>.gitignore</code> and <code>sources</code> 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 <code>cvs add</code> command, e.g.:
+
If you just have a small patch, initscript, or otherwise plain text file, you can commit those directly to git.  This can be done with the <code>git add</code> command, e.g.:
<pre>cvs add packagename-fix-the-foobar.patch
+
<pre>git add packagename-fix-the-foobar.patch
 
</pre>
 
</pre>
  
* 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. For example, to build just for x86_64:
+
* Use the command <code>fedpkg mockbuild</code> to test a package build on your local mock 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. For example, to build just for x86_64:
<pre>make srpm; koji build --scratch --arch-override x86_64 dist-f14 packagename-version-release.src.rpm
+
<pre>fedpkg srpm
 +
koji build --scratch --arch-override x86_64 f18 packagename-version-release.src.rpm
 
</pre>
 
</pre>
  
 
* Check if everything that has changed is correct with
 
* Check if everything that has changed is correct with
<pre>cvs diff -u
+
<pre>fedpkg diff
 
</pre>
 
</pre>
  
 
* Commit the verified changes to the <code>devel/</code> branch.
 
* Commit the verified changes to the <code>devel/</code> branch.
<pre>cvs commit
+
<pre>fedpkg commit
 +
git push
 
</pre>
 
</pre>
 +
 +
* Commit and push in one go
 +
<pre>fedpkg commit -p</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 i686''' 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:
 
<pre>make tag
 
</pre>
 
  
 
* Instruct the builders to build your package:
 
* Instruct the builders to build your package:
<pre>make build
+
<pre>fedpkg build
 
</pre>
 
</pre>
  
Line 221: Line 230:
  
 
<pre>
 
<pre>
fedora-cvs foo
+
fedpkg clone foo
cd foo/devel
+
cd foo
 
wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2
 
wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2
make new-sources FILES="foo-0.0.2.tar.bz2"
+
fedpkg new-sources foo-0.0.2.tar.bz2
 
gedit foo.spec
 
gedit foo.spec
 
# change the required things in the specfile
 
# change the required things in the specfile
make i686
+
fedpkg mockbuild
 
# check that the changes you made are correct
 
# check that the changes you made are correct
cvs diff -u
+
fedpkg diff
# commit
+
# commit and push
cvs commit -m "Update to 0.0.2"
+
fedpkg commit -m "Update to 0.0.2" -p
 +
</pre>
 +
 
 +
{{Admon/important| Note: Be careful that requesting a build on Rawhide is enough, when that build is successful, for that build to reach the Rawhide repository/build-root after a few hours. Before pressing the Enter key after the following command, it is not a bad idea to think again at the potential consequences on the other packages. }}
 +
 
 +
<pre>
 
# request build
 
# request build
make tag build
+
fedpkg build
 
</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, 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]].
+
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 [[#Working_with_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 253: Line 267:
  
 
<pre>
 
<pre>
koji untag-pkg dist-f13 foo-1.1.3-1.fc13
+
koji untag-pkg f18 foo-1.1.3-1.fc18
 
</pre>
 
</pre>
  
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.
+
Where <code>foo-1.1.3-1.fc18</code> is replaced with the name of your package build.  See <code>koji help</code> or [[PackageMaintainers/UsingKoji | UsingKoji]] for more information.
 +
 
 +
=== Requesting special dist tags ===
 +
When updating a package affects a large number of dependencies (e.g. all perl, python or ghc packages) it may be better to initially do the builds in another repo, so that there is less disruption in rawhide.
 +
 
 +
If you think you have an update that falls under this case you can request a special dist tag by filing a [https://fedorahosted.org/rel-eng/newticket release engineering ticket]. Someone from release engineering will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need.
  
 
= Working with packages in the stable branches =
 
= Working with 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.
+
Stable branches are branches within git 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-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.
+
# Switch to the branch which you would like to update with the <code>fedpkg switch-branch</code> command. Here is an example of an update for {{FedoraVersion|long|current}}: {{command|fedpkg switch-branch f{{FedoraVersionNumber|current}}}}
# 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.
+
# Make any required changes. 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.
# Commit the verified changes to the branch you are working on: <pre>cvs commit</pre>
+
# Use the command {{command|fedpkg local}} 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.
# Tag your package: <pre>make tag</pre>
+
# Commit the verified changes to the branch you are working on: {{command|git commit}} and {{command|git push}}. Example of {{command|git push}}: {{command|git push origin f{{FedoraVersionNumber|current}}:refs/heads/f{{FedoraVersionNumber|current}}/master}}. See also [[Using_Fedora_GIT#Branch_names | Fedora branch names]].
# Instruct the builders to build your package:<pre>make build</pre>
+
# Instruct the builders to build your package: {{command|fedpkg build}}
 
# 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 want to build a package for the Pending {{FedoraVersion|long|next}} but it requires package that is not yet pushed "stable" for Fedora 13.
+
* If you want to build a package for the Pending {{FedoraVersion|long|next}} but it requires package that is not yet pushed "stable" for {{FedoraVersion|long|next}}.
 
# You would need to file a buildroot override tag request as outlined in the policy page Alpha_Freeze_Policy
 
# You would need to file a buildroot override tag request as outlined in the policy page Alpha_Freeze_Policy
 
# Once tagged, you can proceed to build her package and issue the [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] request
 
# Once tagged, you can proceed to build her package and issue the [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] request
Line 274: Line 293:
 
== 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>.
+
# This can be accomplished in a few different ways.  The easiest being: {{command|fedpkg update}}. If your local username differs from that of your Fedora account, you will need to specify it with the following command: <code>BODHI_USER=foo fedpkg update</code> Or you add <code>export BODHI_USER=foo</code> to the file <code>~/.bashrc</code> and run the following command:
 +
<pre>
 +
source ~/.bashrc
 +
fedpkg update
 +
</pre>
 
## Alternatively, you can also submit your update using the [https://fedorahosted.org/bodhi/wiki/CLI bodhi-client]
 
## 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] .
 
## or the [https://admin.fedoraproject.org/updates web interface] .
Line 286: Line 309:
  
 
== Reference ==
 
== Reference ==
http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq
+
 
 +
* http://fedoraproject.org/wiki/Using_git_FAQ_for_package_maintainers

Revision as of 06:12, 4 April 2013

Note.png
Run git config --global --add push.default tracking which instructs git to "push" to whatever branch you are tracking

This document shows how to update a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories.

This document is divided in three sections to give Developers, Testers, and Mirror Admins some guidelines on how to submit packages for rawhide, development and pending.

Contents

Overview

Here you can find detailed information on process of Package Management in Fedora. If you want to know the difference between rawhide, development and pending , and which one is suitable for you, along with an overall understanding of the release naming and repos, visit our new and improved Fedora Development Process Overview page.

New contributors (mandatory reading), new Testers (highly suggested reading), new Consumers (useful reading), or anybody interested in how Fedora is developed would find this page useful.

In particular, these are the new paths on mirrors:

  • /pub/fedora/linux/development/rawhide/ will become the new path of Rawhide. It will continue to not have install images, and will be the place where builds from the "devel" branch in git go to. It'll be Fedora 21 intended content.
  • /pub/fedora/linux/development/20 will become the new path of the branched Fedora 20 content. This is where builds from the F-20/ branch in git will go after they pass through Bodhi as "stable".
  • /pub/fedora/linux/updates/testing/20/ will be where potential Fedora 20 builds go after passing through bodhi as "testing". This is where you'll find the latest stuff proposed for freeze break and where testing and peer review of these freeze breaks will happen. When a maintainer feels enough testing has happened, or enough karma triggers the Bodhi auto request, the build will be marked "stable" and show up in the development/20 tree at the next nightly compose.

(View NFR coming soon! New paths on mirrors!)

For Developers

Note.png

If you want to build a new package, but you aren't sure if it should go to Rawhide or Fedora 21, then:

  1. New packages should always be built at least for Rawhide
  2. New packages can be built for Pending and existing Fedora Releases, however they should go through updates-testing first. If the new package is critical-path it will require net positive karma from Releng / QA and peers as outlined below.
Check out and build from the devel/branch No action required. Happens nightly automatically Check out and build from the F21/branch Request a testing update in Bodhi for F21. Bodhi admins push it. Peers test the update and provide karma feedback via Bodhi Request a push to stable within Bodhi. Bodhi admins push it.
Build for Rawhide X
Build for Rawhide + testing in other branches X
Build non-critical path package for F21 (branched) X
Build critical-path for F21 (branched) X
Push critical-path package waiting in "pending" updates-testing repo for a week without karma feedback X[1] X[1]
For a package, in critical path, in the "pending" updates-testing repo for a week that hasn't received karma feedback X[2]
To mark, built package for F21, available for testing X X
To mark stable and tagged for F21 tested update X[3]
To push a package built to handle an urgent issue (e.g. security problem, non-functioning system, etc.) to the F21 branch [4] X[5]

Notes


  1. 1.0 1.1 Mutually exclusive.
  2. Query QA/Release Engineering, too
  3. Provided the package has net positive Karma from QA or releng and at least one more net positive karma point. If karma autopush is checked submit to stable is done automatically
  4. In all cases, it's necessary to be very very very sure the update will not cause additional problems
  5. If the package is not in the critical path, nor addressing a security problem, then it can be requested a push to stable
    If the package addresses a security issue then it should be marked as security. Wait for the Security team to sign off on the update (not sure how this happens right now) before requesting the package be pushed to stable
    If the package is in the critical path, then wait for a QA/Release Engineering/Peer net positive karma vote in Bodhi before requesting the package be pushed to stable


File a buildroot override tag request as outlined in the Policy page, and proceed to build the package Issue the Bodhi request
To build a package for the Pending F21 which requires a package not yet pushed stable for F21 X X


Idea.png
To check and see if the build will be in the Fedora 21, as they will be tagged with "f1?", you can run koji latest-pkg f1? to see what the latest build of your package is for Fedora 21.


For Testers

Read the Rawhide page and follow instructions Keep the rawhide repo enabled and fedora, updates, & updates-testing repos disabled. Consume the rawhide firehose and report issues as you find them. Install from Alpha, Beta, the Last Known Good Pending snapshot or a Pending nightly live image yum update to the latest pending content Update your Fedora 12 system by reading instructions at FIXME Check the QA/Join page that describes the different testable repos, skill level and investment involved. Read the Package Acceptance Test Plan and use it as a guideline
To install Rawhide on your system to test the latest packages X X X
To install and run Fedora 21 as your desktop and participate in test days X X
To update a Fedora 12 system to the Pending Fedora 13 for testing X
To provide test feedback for new packages X
To represent the QA team in providing feedback on critical path package updates X X


Note.png
If you are a member of the QA FAS group, and provided positive feedback on a 'pending' or 'stable' package update. The package update is released and includes a major regression. What now?
  1. Review in weekly QA meeting. It's ok, mistakes happen.
  2. Accident/omission.
  3. Misuse

For Mirror Admins

  • If you are a mirror admin and want to prepare for additional repos coming to your mirror :
    • Read mirror-list(-d) and watch for announcements regarding new paths being added to the Master Mirror.
    • Check your sync exclusion settings to ensure you either get, or don't get the new path (depending on your needs).

Build a package for Rawhide

To build a package for Rawhide, check it out from the git devel/branch.

Install fedora-packager if not already installed.

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

fedpkg clone <package_name>
Important.png
Note: If you are not a member of the fedora packager group, you will receive a "permission denied" error. Use the -a flag to clone anonymously.
Important.png
Note: If you you use a separate ssh key for FAS, remember to load it into your ssh-agent.
  • 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

fedpkg new-sources /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:

fedpkg new-sources yournewtarball.tar.gz yourdata.tar.gz

This also updates your local copy of the .gitignore 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 .gitignore 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:

fedpkg upload somefile.tar.gz

Contrary to fedpkg new-sources, this does not purge old files from the .gitignore and sources files.

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

git add packagename-fix-the-foobar.patch
  • Use the command fedpkg mockbuild to test a package build on your local mock 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. For example, to build just for x86_64:
fedpkg srpm
koji build --scratch --arch-override x86_64 f18 packagename-version-release.src.rpm
  • Check if everything that has changed is correct with
fedpkg diff
  • Commit the verified changes to the devel/ branch.
fedpkg commit
git push
  • Commit and push in one go
fedpkg commit -p

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.

  • Instruct the builders to build your package:
fedpkg build

Example

fedpkg clone foo
cd foo
wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2
fedpkg new-sources foo-0.0.2.tar.bz2
gedit foo.spec
# change the required things in the specfile
fedpkg mockbuild
# check that the changes you made are correct
fedpkg diff
# commit and push
fedpkg commit -m "Update to 0.0.2" -p
Important.png
Note: Be careful that requesting a build on Rawhide is enough, when that build is successful, for that build to reach the Rawhide repository/build-root after a few hours. Before pressing the Enter key after the following command, it is not a bad idea to think again at the potential consequences on the other packages.
# request build
fedpkg 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 the next release. You may want to wait for this release instead of back-porting a fix yourself, 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 f18 foo-1.1.3-1.fc18

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

Requesting special dist tags

When updating a package affects a large number of dependencies (e.g. all perl, python or ghc packages) it may be better to initially do the builds in another repo, so that there is less disruption in rawhide.

If you think you have an update that falls under this case you can request a special dist tag by filing a release engineering ticket. Someone from release engineering will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need.

Working with packages in the stable branches

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

  1. Switch to the branch which you would like to update with the fedpkg switch-branch command. Here is an example of an update for Fedora 20: fedpkg switch-branch f20
  2. Make any required changes. 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.
  3. Use the command fedpkg local 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.
  4. Commit the verified changes to the branch you are working on: git commit and git push. Example of git push: git push origin f20:refs/heads/f20/master. See also Fedora branch names.
  5. Instruct the builders to build your package: fedpkg build
  6. Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.
  • If you want to build a package for the Pending Fedora 21 but it requires package that is not yet pushed "stable" for Fedora 21.
  1. You would need to file a buildroot override tag request as outlined in the policy page Alpha_Freeze_Policy
  2. Once tagged, you can proceed to build her package and issue the Bodhi request

Submit your update to Bodhi

  1. This can be accomplished in a few different ways. The easiest being: fedpkg update. If your local username differs from that of your Fedora account, you will need to specify it with the following command: BODHI_USER=foo fedpkg update Or you add export BODHI_USER=foo to the file ~/.bashrc and run the following command:
source ~/.bashrc
fedpkg update
    1. Alternatively, you can also submit your update using the bodhi-client
    2. or the web interface .
  1. 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 .
  2. 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.
  3. 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.
  4. 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!

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.

Reference