From Fedora Project Wiki

(Dump in my notes from epel pushing)
Line 1: Line 1:
 
== Description ==
 
== Description ==
 
Fedora updates for released er releases are typically pushed once a work day.  This SOP covers the steps involved.
 
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 ==
 
== Action ==
  
1. install <code>bodhi-client</code> on your local workstation
+
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>
 
<pre>
yum install <I don't know>
+
$ bodhi -P --push-release F12 --push-release F13
 
</pre>
 
</pre>
  
2. refresh login cache
+
{{admon/warning|WAIT!| Do NOT press "Yes" yet. Simply view the list and say 'n'.}}
<pre>
 
$ bodhi -m
 
</pre>
 
  
3. Get a list of packages to push
+
List the releases above you wish to push from: F12, F13, F14, EL4, EL5.
<pre>
 
$ bodhi -P --push-release F12 --push-release F13
 
</pre>
 
  
{{admon/warning|WAIT!| Do NOT press "Yes" yet.}}
+
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.
  
4. Copy build names to signing host, one package name per line
+
4a. For Fedora releases: Sign builds using scripts/sigulsign_unsigned.py from releng git repo
 
<pre>
 
<pre>
'''FIXME'''--commands?
+
$ sigulsign_unsigned.py -vv --write-all fedora-13 $(cat *F*)
 
</pre>
 
</pre>
  
5. Sign builds using scripts/sigulsign_unsigned.py from releng git repo
+
4b. For EPEL releases: Sign builds using scripts/sign_unsigned.py from releng git repo
 
<pre>
 
<pre>
$ ./sigulsign_unsigned.py -vv --write-all fedora-13 $(cat tosign)
+
$ sign_unsigned.py --level=EPEL --write-rpms --builds $(cat *EL*)
 
</pre>
 
</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'''}}
 
{{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'''}}
  
6. Press yes on bodhi push command.  If prompted for a password CTRL+c and start over.
+
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 ==
 
== Verification ==
1. Tail the bodhi server log to watch progress on releng2:
+
1. Tail the bodhi server log to watch progress on releng02 or relepel01.
 
<pre>
 
<pre>
$ sudo tail -f /var/log/bodhi/server.log
+
$ tail -f /var/log/bodhi/server.log
 
</pre>
 
</pre>
  
2. Wait for the bodhi masher report (sent to bodhi-adminmember@fp.o) for success/failure.
+
2. Wait for the bodhi masher report (sent to bodhi-adminmember@fp.o) for success/failure or errors in the logs.  
  
 
== Consider Before Running ==
 
== Consider Before Running ==
Line 48: Line 48:
 
$ bodhi -P --resume-push
 
$ bodhi -P --resume-push
 
</pre>
 
</pre>
* '''FIXME'''--include a listing common failure cases and how to work around them
+
 
 +
== 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]]

Revision as of 20:37, 10 September 2010

Description

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

$ bodhi -P --push-release F12 --push-release F13
Warning.png
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

$ sigulsign_unsigned.py -vv --write-all fedora-13 $(cat *F*)

4b. For EPEL releases: Sign builds using scripts/sign_unsigned.py from releng git repo

$ sign_unsigned.py --level=EPEL --write-rpms --builds $(cat *EL*)
Stop (medium size).png
Run this process from screen
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.

$ 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.

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> <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.