Updating NSS

Updating NSS

Here we describee 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 paches, usually for nss only, and do not require the special precautions that are descrived here.

For a full update of three pacakes you will need to build the packages is this order: nss-util, nss-softokn, and nss.

In Rawhide the buildroot is updated frequently and we can also count on chained builds. This is not the case on the stable branches - or on the branch for the next fedora release after the branching which occurs with alpha. 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.

Submitting scratch builds is not sufficient 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 do it for nss.

Building nss, nss-sotokn and nss-util using mock.

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

Use Mock outside your git sandbox to build nss-util

Make nss-util using mock and also create the srpms for nss-softokn and nss which we will build inside the sandbox.

cd {were-the git-checkouts-are}/nss-util; fedpkg srpm
mock -r fedora-rawhide-x86_64 --rebuild nss-util-{v}-{r}.fc15.src.rpm 
cd ../nss-softokn; fedpkg srpm
cd ../nss; fedpkg srpm

Use Mock inside your git sandbox to build nss-softokn and nss First, initialize the mock repository:

mock -r fedora-rawhide-x86_64 --init

Install the packages needed to build nss-softokn and nss (named in BuildRequires) from the yum repositories and local RPMs.

mock -r fedora-rawhide-x86_64 --install \
sqlite-devel zlib-devel pkgconfig gawk psmisc perl nss-devel
mock -r fedora-rawhide-x86_64 --install nss-util-{v}-{r}.fc15.rpm \
nss-util-devel-{v}-{r}.fc15.rpm

Copy in the nss-softokn source RPM into /tmp (we'll copy in and do a build inside the shell, to work around the checks that detect that the packages aren't in the repository):

mock -r fedora-rawhide-x86_64 --copyin /PATH/TO/NSS_SOFTOKN_SRPM_NAME /tmp
mock -r fedora-rawhide-x86_64 --copyin /PATH/TO/NSS_SRPM_NAME /tmp

Shell into the mock environment and perform the builds:

mock -r fedora-rawhide-x86_64 --shell
cd
rpmbuild --rebuild /tmp/nss-softokn-{v}-{r}.fc15.src.rpm

Prepare to Build nss First add yourself as a user, password doesn't matter, to run the build (and test) as yourself not root. If the system doesn't find you it will run as root and this will cause two tests to fail.

userdd yourname 
cd /builddir/build/rpms
rpm -Uhv nss-softokn-{v}-{r}.fc15.rpm nss-softokn-freebl-{v}-{r}.fc15.rpm   nss-softokn-devel-{v}-{r}.fc15.rpm    nss-softokn-freebl-devel-{v}-{r}.fc15.rpm

QESTION: Do we need this step?

Now we are ready to build nss

cd
su yourname
rpmbuild --rebuild /tmp/nss-{v}-{r}.fc15.src.rpm

The nss build will take some time because we run all tests Once it suceeds you can install it and try a client application The results are in /home/yourname/rpmbuild/RPMS/x86_64

exit (bring you back to being root)
cd /home/yourname/rpmbuild/RPMS/x86_64
rpm -Uhv {list-of-rpms}
su yourname
rpm -q curl will confirm that it is installed, use it to access a site
$ curl https://fedoraproject.org/wiki/Bodhi_Guide

Now we are confident that the real builds will work. We haven't done much testing. Can we build another packkage 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 and can and should take advange of chained builds.

# Chained build of nss for Rawhide
fedpkg chain-build nss-util nss-softokn 

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 may be a good idea.

# Chained build of nss for Rawhide
fedkg clone xulrunner
fedpkg srpm
fedpkg scratch-build XULRUNNER_SPRM

Now we can proceed to the stable branches. These will take some time.