From Fedora Project Wiki
(Update for current releases and issues.) |
|||
| Line 1: | Line 1: | ||
== Description == | == Description == | ||
Fedora updates for released er releases are typically pushed once a | Fedora updates for released er releases are typically pushed once a 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. | Note that the process is slightly different between EPEL and Fedora releases. Fedora Rawhide and EPEL-6 do not need or use this process. | ||
| Line 8: | Line 8: | ||
=== Login to a machine that is configured for sigul client support and has the bodhi client installed. If you have not configured your workstation, you can use: === | === Login to a machine that is configured for sigul client support and has the bodhi client installed. If you have not configured your workstation, you can use: === | ||
# For EPEL-4, EPEL-5: relepel01. | # For EPEL-4, EPEL-5: relepel01. | ||
# For | # For F13, F14: releng02. | ||
=== Decide what releases you're going to push. === | === Decide what releases you're going to push. === | ||
| Line 15: | Line 15: | ||
=== Get a list of packages to push === | === Get a list of packages to push === | ||
<pre> | <pre> | ||
$ bodhi -P --push-release | $ bodhi -P --push-release F13 --push-release F14 | ||
</pre> | </pre> | ||
{{admon/warning|Blank list?| If the list is blank, that means the prior push failed, and manual intervention may be required. See 'Common Issues' below.}} | {{admon/warning|Blank list?| If the list is blank, that means the prior push failed, and manual intervention may be required. See 'Common Issues' below.}} | ||
| Line 26: | Line 26: | ||
=== Sign the packages. === | === Sign the packages. === | ||
* For Fedora releases | * For Fedora releases: Sign builds using scripts/sigulsign_unsigned.py from releng git repo | ||
<pre> | <pre> | ||
$ sigulsign_unsigned.py -vv --write-all fedora-13 $(cat *F13) | $ sigulsign_unsigned.py -vv --write-all fedora-13 $(cat *F13) | ||
| Line 39: | Line 39: | ||
{{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'''}} | {{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'''}} | ||
=== | === Repeat gathering updates and signing steps === | ||
After gathering the list of updates and signing them, repeat the process until there are no new updates to be signed. You want to do this because as you are signing updates, maintainers are submitting new ones. There is a window while you are signing that a new update will be added and if you just push then, the push will fail with an unsigned package. | |||
=== Perform the bodhi push === | === Perform the bodhi push === | ||
| Line 66: | Line 67: | ||
* When the push fails due to an old package that has no signature, run: koji write-signed-rpm <gpgkeyid> <n-v-r> and resume. | * When the push fails due to an old package that has no signature, run: koji write-signed-rpm <gpgkeyid> <n-v-r> 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> <n-v-r> to untag the package 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> <n-v-r> to untag the package and resume. You may need to add --force. | ||
* When the push fails due to a package not being tagged with updates-testing when being moved stable: koji tag-pkg dist-<tag>-updates-testing <n-v-r> | * When the push fails due to a package not being tagged with updates-testing when being moved stable: koji tag-pkg dist-<tag>-updates-testing <n-v-r> | ||
* 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. | * 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. | ||
* When signing fails, you may need to ask that the sigul bridge or server be restarted. | |||
* When an update was deleted from bodhi, it may still be in the updates-testing tag. You may need to: koji untag-pkg <tag> <n-v-r> to untag the package and resume. You may need to add --force. | |||
Other issues should be addressed by releng or bodhi developers in #fedora-admin. | Other issues should be addressed by releng or bodhi developers in #fedora-admin. | ||
[[Category:Release Engineering SOPs]] | [[Category:Release Engineering SOPs]] | ||
Revision as of 19:34, 23 December 2010
Description
Fedora updates for released er releases are typically pushed once a 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
Login to a machine that is configured for sigul client support and has the bodhi client installed. If you have not configured your workstation, you can use:
- For EPEL-4, EPEL-5: relepel01.
- For F13, F14: releng02.
Decide what releases you're going to push.
Don't mix types
Please do not push Fedora and EPEL in the same push. Also, please do not push updates for a branched fedora pre-release at the same time as updates for released Fedora.
Please do not push Fedora and EPEL in the same push. Also, please do not push updates for a branched fedora pre-release at the same time as updates for released Fedora.
Get a list of packages to push
$ bodhi -P --push-release F13 --push-release F14
Blank list?
If the list is blank, that means the prior push failed, and manual intervention may be required. See 'Common Issues' below.
If the list is blank, that means the prior push failed, and manual intervention may be required. See 'Common Issues' below.
WAIT!
Do NOT press "Yes" yet. Simply view the list and say 'n'.
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.
The list of updates should be in your homedirectory named 'Stable-$Branch' or 'Testing-$Branch' for each of the Branches you wished to push.
Sign the packages.
- For Fedora releases: Sign builds using scripts/sigulsign_unsigned.py from releng git repo
$ sigulsign_unsigned.py -vv --write-all fedora-13 $(cat *F13)
(Make sure you sign each release with the right key... ie, 'fedora-13' key with F13 packages)
- For EPEL4 and 5 releases: Sign builds using scripts/sign_unsigned.py from releng git repo
$ sign_unsigned.py --level=EPEL --write-rpms --builds $(cat *EL5 *EL4)
.png){kind=small}
Run this process from
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
screenIt 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
Repeat gathering updates and signing steps
After gathering the list of updates and signing them, repeat the process until there are no new updates to be signed. You want to do this because as you are signing updates, maintainers are submitting new ones. There is a window while you are signing that a new update will be added and if you just push then, the push will fail with an unsigned package.
Perform the bodhi push
Re-run the earlier bodhi command from step 2 and say 'y' to push.
Verification
1. Tail the bodhi server log to watch progress on releng02 or relepel01.
$ tail -f /var/log/bodhi/server.log
2. Wait for the bodhi masher report (sent to bodhi-adminmember@fp.o) for success/failure or errors in the logs. Alternatively, wait for the update reports to be sent to the EPEL or test lists.
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
$ bodhi -P --resume-push
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> <n-v-r> 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> <n-v-r> to untag the package and resume. You may need to add --force.
- When the push fails due to a package not being tagged with updates-testing when being moved stable: koji tag-pkg dist-<tag>-updates-testing <n-v-r>
- 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.
- When signing fails, you may need to ask that the sigul bridge or server be restarted.
- When an update was deleted from bodhi, it may still be in the updates-testing tag. You may need to: koji untag-pkg <tag> <n-v-r> to untag the package and resume. You may need to add --force.
Other issues should be addressed by releng or bodhi developers in #fedora-admin.