----- Original Message -----
> From: "Shawn Wells" <[email protected]>
> To: [email protected]
> 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"<[email protected]>
> >> >To: "SCAP Security Guide"<[email protected]>
> >> >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.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
> _______________________________________________
> scap-security-guide mailing list
> [email protected]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
