|
|
| (46 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| == Description ==
| | {{admon/important|This page has moved [https://docs.pagure.org/releng/sop_pushing_updates.html here]| All Fedora Release Engineering Documentation has moved [https://docs.pagure.org/releng/ here] with source hosted along side the code in the [https://pagure.io/releng releng pagure repository]}} |
| Fedora updates for released er releases are typically pushed once a work day. This SOP covers the steps involved. | |
|
| |
|
| Note that the process is slightly different between EPEL and Fedora releases. Fedora Rawhide and EPEL-6 do not need or use this process.
| |
|
| |
|
| == Action ==
| |
|
| |
| 1. Login to the updates compose machine. For EPEL-4, EPEL-5: relepel01. For F12, F13, F14: releng02.
| |
|
| |
| 2. Get a list of packages to push
| |
| <pre>
| |
| $ bodhi -P --push-release F12 --push-release F13
| |
| </pre>
| |
|
| |
| {{admon/warning|WAIT!| Do NOT press "Yes" yet. Simply view the list and say 'n'.}}
| |
|
| |
| List the releases above you wish to push from: F12, F13, F14, EL4, EL5.
| |
|
| |
| 3. The list of updates should be in your homedirectory named 'Stable-$Branch' or 'Testing-$Branch' for each of the Branches you wished to push.
| |
|
| |
| 4a. For Fedora releases: Sign builds using scripts/sigulsign_unsigned.py from releng git repo
| |
| <pre>
| |
| $ sigulsign_unsigned.py -vv --write-all fedora-13 $(cat *F*)
| |
| </pre>
| |
|
| |
| 4b. For EPEL releases: Sign builds using scripts/sign_unsigned.py from releng git repo
| |
| <pre>
| |
| $ sign_unsigned.py --level=EPEL --write-rpms --builds $(cat *EL*)
| |
| </pre>
| |
|
| |
| {{admon/caution|Run this process from <code>screen</code>| It is strongly suggested that the above procedure be run from screen. Doing so requires a host configured as sigul client. See the sigul client SOP '''NEED LINK'''}}
| |
|
| |
| 5. For EPEL releases, check the web interface to make sure all packages have followed the guidelines. Two weeks in testing or +3 karma or security update before allowing to go to stable.
| |
|
| |
| 6. re-run the bodhi command from step 2 and say 'y' to push.
| |
|
| |
| == Verification ==
| |
| 1. Tail the bodhi server log to watch progress on releng02 or relepel01.
| |
| <pre>
| |
| $ tail -f /var/log/bodhi/server.log
| |
| </pre>
| |
|
| |
| 2. Wait for the bodhi masher report (sent to bodhi-adminmember@fp.o) for success/failure or errors in the logs.
| |
|
| |
| == Consider Before Running ==
| |
| Pushes often fall over due to tagging issues or unsigned packages. Be prepared to work through the failures and restart pushes from time to time
| |
| <pre>
| |
| $ bodhi -P --resume-push
| |
| </pre>
| |
|
| |
| == Common issues / problems with pushes ==
| |
|
| |
| * When the push fails due to new unsigned packages that were added after you started the process. re-run step 4a or 4b with just the package names that need to be signed, then resume.
| |
|
| |
| * When the push fails due to an old package that has no signature, run: koji write-signed-rpm <gpgkeyid> <packagename> and resume.
| |
|
| |
| * When the push fails due to a package moving from testing to stable and leaving an old version of the same package in testing: koji untag-pkg <tag> <packagename> to untag the package and resume.
| |
|
| |
| * When the push fails and you see in the server.log "Identity shutting down", bodhi has quit for some reason. Do "sudo service httpd restart" and resume the push.
| |
|
| |
| Other issues should be addressed by releng or bodhi developers in #fedora-admin.
| |
|
| |
|
| [[Category:Release Engineering SOPs]] | | [[Category:Release Engineering SOPs]] |
