[PATCH] [RHEL] Make new 0.1.17 release

Shawn Wells shawn at redhat.com
Mon May 12 20:03:23 UTC 2014

On 5/9/14, 2:04 PM, Jan Lieskovsky wrote:
> ----- Original Message -----
>> From: "Shawn Wells" <shawn at redhat.com>
>> To: scap-security-guide at lists.fedorahosted.org
>> Sent: Friday, May 9, 2014 6:03:20 PM
>> Subject: Re: [PATCH] [RHEL] Make new 0.1.17 release
>> On 5/9/14, 10:24 AM, Jan Lieskovsky wrote:
>>> ----- Original Message -----
>>>>> From: "David Smith"<dsmith at secure-innovations.net>
>>>>> To: "SCAP Security Guide"<scap-security-guide at lists.fedorahosted.org>
>>>>> Sent: Friday, May 9, 2014 4:44:14 PM
>>>>> Subject: Re: [PATCH] [RHEL] Make new 0.1.17 release
>>>>> Jan,
>>>>> Totally agreed on the need for the update; ack + thanks!
>>> Thank you, David. Pushed to master. New tarball & EPEL build to come
>>> shortly.
>> Jan, would you be able to document (even informally) the various steps?
>> While only extremely limited people have access to cut RPMs, it'd be
>> good to document things.
> Sure thing (should I forgot some item - doing them on per moment basis
> when realized forgot to do some of them, will re-iterate later).
> Upstream process:
> * update main scap-security-guide.spec file (scap-security-guide/scap-security-guide.spec)
>    with new version (value of "redhatssgversion" version variable). Ensure
>    the Release: field contains 1%{?dist} (1 as release version). Add particular
>    changelog entry (possibly verify for & fix whitespace noise)
> * build & 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
>    it the content works
> * 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.
> EPEL process:
> * 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#2: It would be created automa{g,t}ically once the "latest upstream source tarball checking Red Hat
>            Bugzilla functionality" would realize there's is new source tarball available. But since we wan't
>            immediate upgrade, we create that bug manually.
> * take that bugzilla (state change NEW => ASSIGNED)
> * 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/
> * 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:
>      origin/el6
>      origin/epel7
>      origin/f18
>      origin/f19
>      origin/f20
>      origin/master
>    To switch to el6 branch, issue:
>      $ fedpkg switch-branch el6
>      Branch el6 set up to track remote branch el6 from origin.
>    command. Now it's possible actually to 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 build during
>      SRPM / RPM build.
> * 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 one 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 woulnd't
>    be present in upstream already. But should there be such changes in the future, the epel-6 spec
>    should be updated to include changes from upstream spec but simultaneously to keep epel-6 custom
>    patches. IOW just replacing epel-6's spec with upstream'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)
> * return back to fedpkg & import the SRPM created in previous steps:
>    $ fedpkg import path_to_srpm
>    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 the changes. The commit message should contain the string:
>    "Resolves: rh bz# id_of_the_epel_6_bug_we_created_before"
>    in point #1 of the EPEL process section.
>    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 be already "git push-ed" to the repository. But since we want to verify if the
>    content would build yet 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 git repository via:
>    $ git push origin el6
>    After successful push, our / latest push should be visible 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 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.
> * Having new build available, it's necessary to schedule new Bodhi update (something like
>    advisory to be tied with new packages). I am using web 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 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                               /* intended for updates fixing bugs */
>                                 enhancement                          /* intended for updates adding new features */
>                                 security                             /* intended for updates fixing security flaws */
>                                 newpackage                           /* intended for updates introducing new RPM packages */
>                 options
>        Request: select 'testing' option of - testing                 /* intended for updates that should reach -testing repository first (before reaching -stable) */
>                                              stable                  /* intended for updates that should go into -stable directly - maybe for critical security updates,
>                                                                         other package updates should be pushed to -testing repository first, then only after some time
>                                                                         into -stable yum repository */
>                                              none                    /* not sure what's this one intended for */
>        Bugs:   provide previously created EPEL-6 RH BZ# id here      [v] Close bugs when update is stable
>                                                                      /* Keep this checkbox checked in. It will automagically close the
>                                                                         created EPEL-6 bug, when the particular build is pushed to -stable yum repository */
>        Notes: Describe the changes in this text field (i.e. which bugs got fixed, which new functionality got introduced 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: []                   /* should the package update require reboot after install */
>       Enable karma automatism: [v]         /* if to use the karma threshold 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 threshold / level of karma build needs to obtain from package testers to be
>                                                     able to push it into -stable channel */
>       Threshold 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 that build being pushed to -testing. After some time at the same day (depending on TZ)
>      the build is pushed to -testing repository.
> * The maintainer should check Bodhi pages 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 reached positive karma >= 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.
> * After 7 days the build can be pushed to -stable (under assumption it didn't reach positive karma >= 3 sooner), meaning in next day or
>    two it's reachable via yum subscribed to epel-6 repository directly.
> * And the whole process goes back to the first item.
> Hopefully I have covered all the points. Should I realize there's missing some yet, will clarify later.

Whoa. This is great.

I've blocked off ~10 hours between now and Fri to catchup on SSG 
activities. I'll spend some of that converting this into DocBook and 
merging into our Developers Guide. It'll give us a solid starting point, 
and should make future edits easier. Will report back Fri on progress 
(+hopefully patches).

More information about the scap-security-guide mailing list