On 4/2/12 2:27 PM, "Shawn Wells" <shawn@redhat.com> wrote:On 4/2/12 1:52 PM, Spencer R. Shimko wrote: On 4/2/12 1:31 PM, "Shawn Wells" <shawn@redhat.com> <mailto:shawn@redhat.com> wrote: > >+rpm: dist/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} + # (3) The value if ${DIST} in this Makefile needs to match + # the %{name}-%{version} string from the .spec file, i.e. + # scap-security-guide-alpha + # (4) If you're making an RPM, chances are the code has changed. Make + # sure you update the %changelog in the .spec to reflect what's new + + # copy template .spec over to rpmbuild + cp ${IN}/rpmbuild/scap-security-guide-alpha.spec ${OUT}/ + + # tar up the sources + tar -zcvf ${OUT}/scap-security-guide-alpha.tar.gz ${DIST} + mv ${OUT}/scap-security-guide-alpha.tar.gz ~/rpmbuild/SOURCES/>+ + # let's see if a build works + rpmbuild -ba ${OUT}/scap-security-guide-alpha.spec + + # Our RPM(s) will be waiting for us in ${HOMEDIR}, so copy them back + mv ~/rpmbuild/RPMS/ ${OUT}/ + ++ + # A few quick notes on preparing your system to build the SSG RPMs: + # (1) May the flies of a thousand horses annoy you for eternity + # if you build an RPM as root. Don't do it! + # (2) This build process assumes you have your rpmbuild structure setup + # $ sudo yum -y install rpm-build + # $ mkdir -p ~*something* in there that would work on a stock RHEL6 build system. What I'd *really* like to see is input/rpmbuild be setup as a localized buildroot which would allow us to be completely self contained (and much more elegant). But I have no idea how to do that and in mucking around it didn't become apparent to me. Hopefully someone with more RPM knowledge than me could patch to make that happen.I'm not happy with assumptions regarding user environment. We don't control rpmbuild or the RPM macros file. Barring those issues this also makes some assumptions about directory structure that might not be correct. All valid. I wanted to getHow about supporting both mock and plain RPM builds? We have a build system that does that internally that we can apply to this situation (we are done with the fragility of build VMs). But the caveat here is that it comes with some rather significant complexity. Not auto make's level of complexity, but perhaps unnecessary complexity for this project. A simpler approach that just handles RPM builds (no mock) can be found here: http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/build/Makefile
<snip>+%install +rm -rf $RPM_BUILD_ROOT +#make install DESTDIR=$RPM_BUILD_ROOT +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/content +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/guide +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/policytables +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/STIG-draft +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/USGCB-submissionHow does this work if $RPM_BUILD_ROOT has spaces? Assumed stock environment. Patches welcome.Cool. FWIW the link I pasted above has the same issue. I'll fix it up in SSG and push a patch soonish.>+/usr/local/scap-security-guide/>+ +%changelog +* Mon Apr 02 2012 Shawn Wells <shawn@redhat.com> <mailto:shawn@redhat.com>><mailto:shawn@redhat.com> <mailto:shawn@redhat.com> 1.0-1 +- First attempt at SSG RPM. May ${diety} help us... diff --git a/rhel6/src/output/.gitignore b/rhel6/src/output/.gitignore index 7206c02..4bbeae5 100644 --- a/rhel6/src/output/.gitignore +++ b/rhel6/src/output/.gitignore @@ -3,3 +3,8 @@ *.html *.pdf *.ini +*.spec +*.tar +*.gz +scap-security-guide-*/ +RPMS/ -- 1.7.1+cp -r * $RPM_BUILD_ROOT/usr/local/%{name}/ + + +%clean +rm -rf $RPM_BUILD_ROOT + + +%files +%defattr(-,root,root,-) +%doc + +%attr(0750,root,root)
Pushed*every* patch hit the mailing list and get 1-2 ack's, but it's been the wild west as we get core content created. While I want it now, I'm thinking that once alpha drops all patches need to be sent out before commits.I'd prefer to wait for at least one ACK before pushing. IMO an ACK from anyone with commit access should be sufficient for a merge/push. Thoughts? Personally I'd like to seeSounds good to me.
-- Shawn Wells Technical Director, U.S. Intelligence Programs (e) shawn@redhat.com (c) 443.534.0130