canmove, Confirmed users
6,441
edits
ReleaseEngineering/PuppetAgain/HowTo/Build RPMs: Difference between revisions
ReleaseEngineering/PuppetAgain/HowTo/Build RPMs (view source)
Revision as of 19:26, 4 June 2018
, 4 June 2018→What to do with these spec files?
| (12 intermediate revisions by 6 users not shown) | |||
| Line 4: | Line 4: | ||
==Build a .src.rpm== | ==Build a .src.rpm== | ||
Use a machine configured to build RPMs, with the toplevel::server::pkgbuilder class. | Use a machine configured to build RPMs, with the toplevel::server::pkgbuilder class, which nowadays is just rpmpackager1. In moco, see [[ReleaseEngineering/How_To/Start_RPM_Ubuntu_Packager_Instances]] and do: | ||
If you're upgrading or modifying an existing package, download the source RPM of the old version of the package you'd like to build from puppetagain.pub.build.mozilla.org/data/repos/yum/releng/public and unpack it: | # May need to be turned on first. | ||
ssh rpmpackager1.srv.releng.use1.mozilla.com | |||
The build infrastructure uses two types of rpm's: vanilla and customized for mozilla. | |||
Let's clarify the terminology: a "vanilla package" is a package which is publicly available and is used by mozilla without applying any customization. An example of this is the jdk package used for Android builds. A "mozilla custom" package is a package rebuilt with some mozilla-related customization in the spec file defining how it is built. An example of this is the mercurial package deployed on slaves across the infrastructure. | |||
Vanilla packages just need to be made available in our repositories, while mozilla-custom ones need to be rebuilt. The procedure described here applies to mozilla-custom packages. | |||
If you're upgrading or modifying an existing mozilla-custom package, you will need the following spec files: | |||
* old vanilla spec file: this is the spec file used to build the old version of the package before applying mozilla customizations | |||
* new vanilla spec file: this is the spec file used to build the new version of the package before applying mozilla customizations | |||
* old mozilla-custom spec file: the spec file used to build the previous mozilla-custom version of the package | |||
.spec files can be obtained from source rpm's as described below. | |||
=== How to extract .spec files from source rpm's === | |||
download the source RPM of the old version of the custom package you'd like to build from puppetagain.pub.build.mozilla.org/data/repos/yum/releng/public and unpack it: | |||
$ mkdir foopkg && cd foopkg | $ mkdir foopkg && cd foopkg | ||
$ rpm2cpio $srpm | cpio -ivd | $ rpm2cpio $srpm | cpio -ivd | ||
You should see a .spec file appear | You should see a .spec file appear. | ||
If you're starting a fresh package, make yourself a new .spec file and download any | === What to do with these spec files? === | ||
Now that you have the old vanilla, new vanilla, and old custom, you should create a new spec file (to be used to build the new version of the package), by merging the diff between old vanilla and old custom (.i.e.: the mozilla customization) into the new vanilla spec file. | |||
Spec files used to build packages used in the infrastructure should be identical to the ones in https://github.com/mozilla/build-puppet under modules/packages/manifests/mozilla. If not, figure out what the differences are, and which corresponds to the running version of the package. | |||
If you're starting a fresh package, make yourself a new .spec file and download any source files archive to the current directory. E.g., in order to build mercurial 3.1.2, mercurial-3.1.2.tar.gz needs to be in $PWD. | |||
Edit the spec file to your heart's content. To actually build the .src.rpm: | Edit the spec file to your heart's content. To actually build the .src.rpm: | ||
$ mock -r puppetagain-centos6-64 --buildsrpm --spec /path/to/spec | $ mock -r puppetagain-centos6.5-64 --buildsrpm --sources $PWD --spec /path/to/spec | ||
The script output will tell you where the SRPM is. Copy it somewhere else, or mock will delete it in the next step. | The script output will tell you where the SRPM is. Copy it somewhere else, or mock will delete it in the next step. | ||
| Line 26: | Line 48: | ||
* If necessary, fetch the .src.rpm you built earlier. | * If necessary, fetch the .src.rpm you built earlier. | ||
* Execute these steps to build: | * Execute these steps to build for both 32 and 64 bit packages: | ||
<pre> | <pre> | ||
$ rm -rf /var/cache/mock/epel-6-x86_64/ccache | $ # 64 bit: | ||
$ mock --rebuild -r puppetagain-centos6-64 mozilla-python27-2.7.3-0.el6.src.rpm | $ rm -rf /var/cache/mock/epel-6.5-x86_64/ccache | ||
$ mock --rebuild -r puppetagain-centos6.5-64 mozilla-python27-2.7.3-0.el6.src.rpm | |||
$ | |||
$ # 32 bit: | |||
$ rm -rf /var/cache/mock/epel-6.5-i386/ccache/ | |||
$ mock --rebuild -r puppetagain-centos6.5-32 mozilla-python27-2.7.3-0.el6.src.rpm | |||
</pre> | </pre> | ||
The script will tell you where the results are available. | The script will tell you where the results are available. | ||
If your build fails with something like "configure: error: cannot compute suffix of object files: cannot compile" in /var/lib/mock/epel-6.5-x86_64/result/build.log, or error messages complaining of a permission denied for /tmp/ccache/0/0 folder, it probably means that the last person to build an rpm didn't do the 'rm -rf' cleanup step. You'll need to do it as root: | |||
<pre> | |||
$ su - | |||
(slave root password) | |||
# rm -rf /var/cache/mock/epel-6.5-i386/ccache/ | |||
# rm -rf /var/cache/mock/epel-6.5-x86_64/ccache | |||
</pre> | |||
== Other Dependencies == | == Other Dependencies == | ||