Wednesday, 18 September 2013

Packaging an RPM from Source Code

This post will reference software that I built in a previous blog post. In that post I failed to build the cpio package but managed to successfully build the gettext package for my system. During this post I will be talking about my attempts to package the source code from these pieces of software into useable RPM packages. IT SHOULD BE NOTED THAT I GAVE MY FEDORA VM AN EXTRA CPU CORE SINCE MY LAST BLOG POST. AS A RESULT, BUILD TIMES SHOULD BE MUCH FASTER.

The first step is to download the source code using the command yumdownloader --source cpio.x86_64 and yumdownloader --source gettext.x86_64. Please note that the packages I got from the Fedora repository were not the latest versions from the GNU project website. Using the command  rpm -i /path/to/src.rpm I was able to install the source into my ~/rpmbuild directory.

Now I attempted to build from source using the command time rpmbuild -ba cpio.spec. The ba option builds all (source and binary packages). During this build however I found a dependency I was missing. It was texinfo. After installing this dependency, I ran the rpmbuild command again. The build appeared to be successful and took 2 minutes and 50 seconds.

Next, I attempted to build from source using the command time rpmbuild -bs cpio.spec. The bs option builds only the source package. This action completed in less than a second and produced a src.rpm in the SRPMS folder. Using the rpmbuild --rebuild cpio-2.11-20.fc19.src.rpm command, I can rebuild the source rpm into a true rpm. As expected, this operation took 2 minutes and 50 seconds. it produced a regular version of the cpio rpm as well as a debug version.

When running rpmlint on my cpio spec file, I was able to have 0 errors and 0 warnings. My spec file was very simple though. Despite this, I was still unable to build cpio due to the same error I mentioned in my previous post.

I then tried to build a gettext rpm from source and received messages about 7 missing dependencies; they are libtool, bison, emacs, chrpath, expat-devel, libcroco-devel, and libunistring-devel. I'm really glad there are tools to work out these dependencies for me. I do not know what I would have done if I were doing this in "the old days".

Building gettext from source was my next step. It took 29 minutes and 35 seconds. Wow. This build created 4 x86_64 packages. They are a developer package, normal package, debug package and library package. It also created 3 packages with no architechture (noarch). These packages were 2 emacs gettext packages and 1 common-developer package.

Using the rpmlint command, I checked the integrity of the getext RPM I created. First I ran rpmlint ~/rpmbuild/SPEC/gettext.spec which determined the spec file had 1 error and 3 warnings. Running the command rpmlint ~/rpmbuild/SRPMS/gettext-0.18.2.1-1.fc19.src.rpm showed me that my source rpm had 1 error and 7 warnings. Finally, running the command rpmlint ~/rpmbuild/RPMS/x86_64/gettext-0.18.2.1-1.fc19.rpm told me that this package had no errors and 5 warnings.

The errors that I encountered were simple as all of them were the same. They all said that the text "Fri Sep 3 1998" is a "bogus date". Despite changing this date to resemble other dates in the file, the problem persisted. I then looked at the calendar for 1998 and discovered Mr. Nottingham had made the mistake of thinking it was Friday instead of Thursday. After changing this, the problem was resolved. The warnings I faced were mostly due to apparent spelling errors (which I could not find) or missing documentation. I could not solve these.

Next I tried to make my own spec file. I encountered errors when I accidentally put the incorrect version number in the version section. When I linked to my source tar ball in the Source0 section of the spec file, the rpmbuilder was unable to continue because it tried to change to the build directory of the version I put in the version number, not the one that the unzipped tarball created.

After trying another build I encounter a problem with the QA_RPATHS variable. I get errors similar to ERROR 0001: file 'samplefilename' contains a standard rpath 'usr/lib64' in [/usr/lib64]. The output of these errors recommended I use the command QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba gettext.spec. To solve this I tried to set this variable inside the %install portion of the spec file. When both of these solutions didn't work, I attempted to pass the %configure macro the --disable-rpaths option as recommended here. These did not seem to work and the build time for gettext is fairly long so I decided to attempt this build another time.

UPDATE
With the help of my teacher, I was able to sort out my rpath issues. The updated spec file can be found here. It includes a very rough fix for rpaths issue (the --disable-rpaths option had no code associated with it). It also includes fixes for the included files. The build succeeded, here is the software.

0 comments :

Post a Comment