From Fedora Project Wiki

 
(3 intermediate revisions by the same user not shown)
Line 23: Line 23:


(If you haven't done so add ourself to the mock group usermod -a -G mock myusername)
(If you haven't done so add ourself to the mock group usermod -a -G mock myusername)
=== Prepare mock outside your git sandbox to build all nss packges ===
Setup some environment variables
<pre>
export nspr_version=4.8.7
export nspr_release=1
export nss_version=3.12.9
export nss_release=1
export target=15
export dist=rawhide
export arch=x86_64        # or i386
export archalso=x86_64    # or i686
</pre>
Initialize the mock environment and install packages needed to build nss
<pre>
mock -r fedora-${dist}-${arch} --init
mock -r fedora-${dist}-${arch} --install sqlite-devel zlib-devel pkgconfig gawk psmisc perl nss-devel nspr-devel
</pre>
Build all the rpm's and copy them into mock
<pre>
cd ./nspr
fedpkg srpm
mock -r fedora-${dist}-${arch} --copyin nspr-${nspr_version}-${nspr_release}.fc${target}.src.rpm /tmp
cd ../nss-util
fedpkg srpm
mock -r fedora-${dist}-${arch} --copyin nss-util-${nss_version}-${nss_release}.fc${target}.src.rpm /tmp
cd ../nss-softokn
fedpkg srpm
mock -r fedora-${dist}-${arch} --copyin nss-softokn-${nss_version}-${nss_release}.fc${target}.src.rpm /tmp
cd ../nss
fedpkg srpm
mock -r fedora-${dist}-${arch} --copyin nss-${nss_version}-${nss_release}.fc${target}.src.rpm /tmp
</pre>
cd ..
Create a mock shell
<pre>
mock -r fedora-${dist}-${arch} --shell
</pre>


=== Use Mock inside your git sandbox to build nspr and nss ===
=== Use Mock inside your git sandbox to build nspr and nss ===


# set the environment variables
Set the environment variables: nspr_version, nspr_release, nss_version, nss_release, target, and arch
<pre>
Build the packages, the nss build will take some time because we run all tests.
export nspr_version=4.8.7
Install the built packages and then built the client packages.
export nspr_release=1
export nss_version=3.12.9
export nss_release=1
export target=f15
export dist=rawhide
export arch=x86_64      # or i386
export archalso=x886_64 # or i686
<pre>
 
<pre>
# For ease of installing later
<pre>
# build nspr, nss-util, and nss-softokn as root
rpmbuild --rebuild /tmp/nspr-${nspr_version}-${nspr_release}.fc${target}.src.rpm
rpm -Uhv nspr-*
rpmbuild --rebuild /tmp/nss-util-${nss_version}-${nss_release}.fc${target}.src.rpm
rpm -Uhv nss-util-*
rpmbuild --rebuild /tmp/nss-softokn-${nss_version}-${nss_release}.fc${target}.src.rpm
rpm -Uhv nss-softokn-*
# build nss as mockbuild
su mockbuild -c 'rpmbuild --rebuild /tmp/nss-${nss_version}-${nss_release}.fc${target}.src.rpm /builddir/build/RPMS'
</pre>
 
The nss build will take some time because we run all tests.
 
# install nss
<pre>
rpm -Uhv \
nss-${nss_version}-${nss_release}.fc${target}.${archalso}.rpm \
nss-sysinit-${nss_version}-${nss_release}.fc${target}.${archalso}.rpm \
nss-tools-${nss_version}-${nss_release}.fc${target}.${archalso}.rpm \
nss-debuginfo-${nss_version}-${nss_release}.fc${target}.${archalso}.rpm \
nss-devel-${nss_version}-${nss_release}.fc${target}.${archalso}.rpm \
nss-pkcs11-devel-${nss_version}-${nss_release}.fc${target}.${archalso}.rpm
</pre>
 
Once it succeeds and installs okay you could try a client application
Once it succeeds and installs okay you could try a client application
The results are in /home/yourname/rpmbuild/RPMS/x86_64
Now we are confident that the real builds will work for both nss and its clients.
<pre>
Once the build succeeds wait for all packages to be in the build root.  
rpm -q curl will confirm that it is installed, use it to access a site
$ curl https://fedoraproject.org/wiki/Bodhi_Guide
</pre>
 
Now we are confident that the real builds will work. We can build another package that is a client of nss.
crypto-utils is a simple client that we could build in our environment, curl is another.
 
The Koji builds should be done in reverse order starting with Rawhide.
In Rawhide we are lucky, we can and should take advantage of chained builds.
 
<pre>
# Chained build of nss for Rawhide
fedpkg chain-build nss-util nss-softokn
</pre>
 
Once the build succeeds wait for all packages to be in the build root. Here one could do a verification that packages that dependd on nss would not be broken by our update. A scratch build of one of them is a good test. A scratch build of xulrunner would proceed as follows.
 
<pre>
# Scratch build of xulrunner for Rawhide
fedkg clone xulrunner
fedpkg srpm
fedpkg scratch-build --srpm path_to_xulrunner_srpm
</pre>
 
There should be no problems with xulrunner or any other package we try.


Now we can proceed to the stable branches. These will take longer as they must be done one by one.
This can be repeated with the stable branches.


=== Useful Scripts ===
=== Useful Scripts ===


Some degree of automation for the process above is needed.
Some degree of automation for the process above is needed.
To that effect, there are some scripts in a git repository.
To that effect, there are some python scripts in a git repository.
They are adapted from scripts written by Kevin Wright for ipa and dogtag.
This is still a work in progress so please ignore the python scripts for now.


git clone git://fedorapeople.org/~emaldonado/nssmockbuilds4fedora.git
git clone git://fedorapeople.org/~emaldonado/nssmockbuilds4fedora.git

Latest revision as of 17:20, 7 February 2013

Here we describe updates that are a rebase of NSS where all three packages need to be be updated. Most updates are simply new releases to incorporate downstream patches, usually for nss only, and may not require all the special precautions that are described here. The rationale for the split of softokn off from nss that occurred in 3.12.4 is described here https://fedoraproject.org/wiki/Features/SplitSoftoknFromNSS.

For a full update of three packages you will need to build them in this order: nss-util, nss-softokn, and nss. On some occassions nspr would be part of the bundle and must be built first.

In Rawhide the buildroot is updated frequently and we also have chained builds. This is not the case on the stable branches - or on the branch for the next fedora release after the alpha branching. In these cases one must wait for one package to be tagged into the buildroot before one can build the subsequent one. Often you will have some urgency. The procedures is to open a ticket asking that the package you built be added to the buildroot and wait until so to proceed to the next one.

WARNING 1: Don't try shortcuts. Do not introduce a BuildRequire that is lower than the Require just so to be able to build the next package right away. It may build but will likely cause breakage later on when you try to install and some package that depends on nss or any of its siblings will fail to install or to build. All three packages have devel sub-packages. The version used for BuildRequire must the one used for Requires.

One must coordinate with release engineering to progressively add packages to the buildroot. It takes waiting. Furthermore, before sending request to release engineering one must get some assurance that all builds will succeed and and will not cause conflicts and avoid repeated requests. Preflight and testing are necessary.

Scratch builds do not help in testing because they will not get installed into the buildroot and we are building several packages which depend on previous ones.

One approach could be to use multiple system builds and installs in various VM's. Once you have downloaded the packages, a 'yum --nogpgcheck localupdate packages-we-have-so-far' is one way to accomplish this. All dependencies must be satisfied and no conflicts shuould result.

A better way is to do mockbuilds and add the packages to our local buildroot as we go along. http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#Building_packages_that_depend_on_packages_not_in_a_repository

Let's expand on how we can follow the procedure outlined above for NSS.

Building nspr, nss-util, nss-sfotoken, and nss-util using mock

(If you haven't done so add ourself to the mock group usermod -a -G mock myusername)

Use Mock inside your git sandbox to build nspr and nss

Set the environment variables: nspr_version, nspr_release, nss_version, nss_release, target, and arch Build the packages, the nss build will take some time because we run all tests. Install the built packages and then built the client packages. Once it succeeds and installs okay you could try a client application Now we are confident that the real builds will work for both nss and its clients. Once the build succeeds wait for all packages to be in the build root.

This can be repeated with the stable branches.

Useful Scripts

Some degree of automation for the process above is needed. To that effect, there are some python scripts in a git repository. They are adapted from scripts written by Kevin Wright for ipa and dogtag. This is still a work in progress so please ignore the python scripts for now.

git clone git://fedorapeople.org/~emaldonado/nssmockbuilds4fedora.git

Comments and Discussion