# Building Official RPMs

The following steps are required to build an official release of the SCAP Security Guide RPM. Please note that exceptionally few people have such access.

## Required Accounts

- Red Hat BugZilla

- Bodhi

- Koji

## Required Software

- fedpkg

## Build Upstream

1. Update main scap-security-guide.spec file (scap-security-guide/scap-security-guide.spec) with new version (value of "redhatssgversion" variable). Ensure that "Release:" field contains 1%{?dist} (1 as release version). Add particular changelog entry (possibly verify for & fix whitespace noise).

2. Build and test the content (i.e. run 'make', 'make srpm', 'make rpm') to verify it builds successfully. Also try to scan some systems with selected profiles to see if the content works.

3. If it works, 'make clean' in the git repository to start with clean table. Make the source tarball via "make tarball". Upload the tarball to repos.ssgproject.org.

## Build EPEL Release

1. file-in new EPEL-6 bugzilla (Summary = "Upgrade scap-security-guide package to scap-security-guide-X.Y.Z").

   NOTE: That bugzilla is required later when creating Bodhi update request. See below.

   NOTE: It would be created automa(g,t}ically once the "latest upstream source tarball checking Red Hat Bugzilla functionality" would realize there is new source tarball available. But since we want immediate upgrade, we create that big manually.

2. Take that BugZilla (state change NEW=>ASSIGNED)

3. Clone the scap-security-guide git repository via fedpkg tool (as documented in: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_Commit.2Cand_Build_Your_Package) section "Check out the module" and later ones). Split into coins for our case it means:

   $ fedpkg clone scap-security-guide

   $ cd scap-security-guide/

4. Ensure to change the git branch from master/ to origin/el6 via 'switch-branch' fedpkg's option (this ensures the changes will be actually committed into EPEL-6 branch, and not into the master, IOW F-21 branch, which we don't want. To see the list of available branches, issue the following:

   $ fedpkg switch-branch -l

   Locals:

   * master

   Remotes:

   orgin/el6

   origin/epel7

   origin/f18

   origin/f19

   origin/f20

   origin/master

   To switch to the el6 branch, issue:

   $ fedpkg switch-branch el6

   Branch el6 set up to track remote branch el6 from origin

   Now it's possible to actually see the actual content of EPEL-6 branch:

   $ ls

   scap-security-guide.spec sources

   scap-security-guide.spec is the SPEC file used for build of EPEL-6's RPM, sources text file contains md5sum of scap-security-guide tarball, which will be built during SRPM / RPM build.

5. To refresh both of them (*.spec & content of source) at once, it's possible to create source RPM package & import it into fedpkg.

   Two important notes to mention here:

   - The spec file needs to be the updated one => it's necessary to update the actual epel-6 one with changes from upstream or replace the epel-6 one with upstream one (the latter is still possible because as of right now there aren't epel-6 downstream specific patches that wouldn't be present in upstream already. But should there be changes in the future, the epel-6 spec should be updated to include changes from upstream spec but simultaneoously to keep epel-6 custom patches. IOW just replacing epel-6's spec with upsteeam's one wouldn't work, but manual changes would be necessary).

   - The new source tarball needs to be the last one uploaded to repos.ssgproject.org (so md5sum would match during package build).

   This means:

   * start with clean /rpmbuild directory structure

   * download latest tarball from repos.ssgproject.org into /rpmbuild/SOURCES

   * place the modified epel-6 spec file into /rpmbuild/SPECS

   * build the source RPM (result will be in /rpmbuild/SRPMS)

   Next, return back to fedpkg & import the SRPM created in the previous step:

   $ fedpkg import path_to_rpm

   This will change content of 'sources' file (include new md5sum) & update scap-security-guide.spec.

   $ git status [to see what will get committed]

   $ git commit [to confirm changes. The commit message should contain the string "Resolves: rh bz# id_of_epel_bug_we_created_before"

   Make scratch build to see the uploaded content (spec + tarball) would actually build in the Koji build system via:

   $ fedpkg scratch-build --srpm path_to_srpm_created_locally_before

   NOTE: scratch-build to work with actually committed git repository content, it requires the new content to already be "git push-ed" to the repository. But since we want to verify if the content would build ye before pushing changes into the EPEL-6 repository, we need to provide the --srpm option pointing fedpkg to the local source RPM package we have created one step before.

   Once the scratch build passes (visible in Koji web interface, or also on command line), we can push the changes to the git repository via:

   $ git push origin el6

   After successful push, our / latest push should be visibile at (in el6 branch) http://pkgs.fedoraproject.org/cgit/scap-security-guide.git/

   Now it's safe (scratch build succeeded & we pushed the changes to the Fedora's git) to build real new package via:

   $ fedpkg build

   This again generates clickable link, at which point it's possible to see the progress / result of the build. Once the new package build in Koji finishes successfully, we flip the previously created EPEL-6 bug to MODIFIED (ASSIGNED => MODIFIED) and mention the new package name-version-release in the "Fixed in Version:" field of that bug.

6. Having new build available, it's necessary to schedule new Bodhi update (something like advisory to be tied with new package). I am using UI:

   https://admin.fedoraproject.org/updates/new/

   but there's command-line interface too (see [1] for further details).

   Add New Update screen is shown (containing the following fields / items):

   Add New Update

   ----------------------------

   Package: name-version-release of Koji build goes here (e.g. scap-security-guide-0.1-16.el6)

   Type: select one of - bugfix /* intented for updates fixing bugs */

   enhancement /* intended for adding new features */

   security /* intended for fixing security flaws */

   newpackage /* intended for updates introducing new RPM packages */

   options

   Request: select "testing" option of -testing /* intended for udpates that should reach -testing repo first, before -stable) */

   -stable /* updates directly into -stable (maybe fore critical) */

   -none /* don't use this */

   Bugs: Provide previously created EPEL-6 RH BZ#, ensure the "Close bugs when update is stable" option is checked!

   Note: Describe the changes in this text field (i.e. which bugs got fixed, which new functionality, etc). The content of this field appear in the advisory (sent on fedora-package-announce mailing list), when the build is pushed to -stable.

   Suggest Reboot: [] (generally leave unchecked)

   Enable karma automatism [v]

   (If to use the karma threshhold the updates push system to use to decide if the build should be pushed to -stable channel or not)

   Threshold for pushing to -stable [3]

   (Minimum level of karma build needs to obtain from package testers to be able to push it into -stable channel)

   Threshhold for unpushing [-3]

   (Lower bound for negative karma, which is a sign for the push system to move the package from the -testing repository. IOW the build has received so much negative karma/experiences, it's not usable even for the -testing repository and should be rebuilt)

   Once all the information is filed, click "Save Update." This will generate automated EMail about the build being pushed to -testing. After some time at the same day (depending on TZ) the build is pushed to -testing repository.

7. The maintainer should check Bohdi packages for that update for positive/negative karma/comments. If the build has reached positive karma >=3 it can be pushed to -stable (if it hasn't reavhed positive karma in >= 3 in 7 days, it will be pushed to -stable; 7 days is considered sufficient period). If there are signs of negative karma, the build should be either unpushed / deleted & new one made.

8. After 7 days the build can be pushed to -stable (under assumption it didn't reach positive karma >= 3 sooner), meaning in the next day or two it's reachable via yum subscribed to epel-6 repository directly.