Tuesday, 30 October 2012

Andora Project Plan

I've decided to work on Andora Project Release project. I will be working on the andora logos and andora release package.


For now we had a meeting with John Selmys and we talked about the basic requirements for this project and also the expectation of this project.

I have checked the current Fedora Andora Remix from school and the first thing I'm planning to do is to design a new logo to replace the current "Hotdog" logo. 

 

I've updated the project plan on Wiki page.

Project Details

This part of project is to design custom logos and wallpaper to replace all of the existing Andora Fedora Remix, as well as the package of Andora-Fedora Remix release files that define the release. 

Project Plan 

0.1 Research what logos and wallpaper need to be changed. How the logos and wallpaper will be integrated into Andora Remix. Provide several logo drafts. Also do research on which release packages need to be released.
0.2 Take the 0.1 release and make any changes or correction that need to be done and test it and release the beta package.
0.3 Final logos, wallpaper and release packages release. (2 packages in total) 


RPM Signing and Repo Creation lab

Purpose

The purpose of this lab is to know the steps to sign RPM packages and create the RPM package repository for use with yum.

Signing RPM packages

First I created my own GPG key by the following command and completed the required infomation.


| gpg --gen-key




At the end the script required 284 more bytes to generate the key. So I had typed some random words in order to complete.

After that, I edited the ~/.rpmmarcos file to add my email address associated with the gpg key in %_gpg_name macro.

I added this line in the bottom of ~/.rpmmarcos file.


%_gpg_name "myemailaddresshere"




With that done I proceed to sign packages. First I installed the rpm-sign package.

| yum install rpm-sign


Then sign the package by using this command.

| rpm --addsign which-2.20-1.fc17.x86_64.rpm



After entering the pass phrase, the signing process was successfully completed. Next step is to create my own yum repo.

Creating the Repository

Move the signed RPM to repo directory and create the repo.


| createrepo .




Then besides the RPM package, the command created a rpmrepo folder which is for creating yum repo.

The last part was to create a new repository file in /etc/yum.repos.d. I copied the existing Fedora repo file and made the following edits.

[wendy]
name=wendy
Baseurl=file:///home/wendy/repo
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/wendy-gpg-key-rpm

The /etc/pki/rpm-gpg/wendy-gpg-key-rpm file was made by exporting my public key file to /home/wendy/repo with the following command.

| gpg --export --armour "myemailaddress" > wendy-gpg-key-rpm


(* Do this with regular user account)

Finally I tested the install by YUM.


It worked! YUM was trying to install the package from my own repository ("wendy").

Repodata directory:



Mock and Koji

Today I'm going to build my packages with mock and koji. Mock is a toll to test that the BuildRequires for the package are complete and accurate. While koji is a client-server system that builds the package on multiple different architectures within the Fedora build farm. It is useful when you don't have access to the machines of each architecture.
 
Let's start with mock.

Mock

Mock takes a srpm and builds it in a chroot. It will tests your BuildRequries lines are correct and no missing dependencies.

Install mock on Fedora, and add current user into mock group.

| yum install mock
| usermod -aG mock wendy

Then I tested to build my SRPM package for Fedora 17 on 64-bit architecture by using mock

| mock -r fedora-17-x86_64 rpmbuild/SRPMS/which-2.20-1.fc17.src.rpm
| mock -r fedora-17-x86_64 rpmbuild/SRPMS/hello-2.80-1.fc17.src.rpm
( * Note: the distribution-release-arch value must correspond to a config file in /etc/mock)

The mock build took longer than the rpmbuild time.

which
real    5m41.030s
user    0m6.307s
sys    0m11.108s

hello

real    1m38.404s
user    0m11.832s
sys    0m20.338s

To check the result and any error during the testing process. I checked the following file, and both of them were good.

| vi /var/lib/mock/fedora-17-x86_64/result/build.log




There was no error so my mock build was successful.

Mock is easy to use since it's only one command, but I like rpmbuild better. For rpmbuild, I can see the source code file and spec file located in separate directories and it is clear and well structured when building the RPM files.

Koji

Koji setup

| yum install fedora-packager

then run this script to setup my certificate that authenticate the package.


| /usr/bin/fedora-packager-setup

This links my FAS account to my Fedora system by making certificate on it. Also it makes a SSL certificate so I can login to the web interface of each Fedora testing farm. After the setup, I imported my certificate into Firefox browser in order to manage the koji web interfaces.


Below are my testing in different architechtures.

Primary i386 and x86_64 

| koji build f17 --scratch SRPMS/which2.20-1.fc17.src.rpm



http://koji.fedoraproject.org/koji/taskinfo?taskID=4605785


ARM armv5tel and armv7hl

| arm-koji build f18 --scratch SRPMS/which2.20-1.fc17.src.rpm

 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1207902

| arm-koji build f18 --scratch SRPMS/hello-2.8-1.fc17.src.rpm

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1217061


s390 mainframe

| s390-koji build f18 --scratch SRPMS/which2.20-1.fc17.src.rpm

 http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=833648


PowerPC

| ppc-koji build f18 --scratch SRPMS/which2.20-1.fc17.src.rpm

 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=754315

| ppc-koji build f18 --scratch SRPMS/hello-2.8-1.fc17.src.rpm

 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=761608

All of my testing builds are passed without any error. The job was sent to each building machine and sent in the queue. It took around 10 to 20 minutes to finish each building depended on the size of package and how busy the queue was.

Done!
 
Overall I think mock and koji are great tools to build RPM packages. It's bacially automated process. They are simply and user friendly to use and especially for beginner packagers. I like the fact that mock allows us to test packages in a chroot environment so we don't need to worry about messing up our own OS. Koji is also a great tool to test all kinds of architectures without accessing the physical hardware of each architecture.




Monday, 22 October 2012

RPM Writing Lab

The purpose of doing this lab is to create an RPM package. So here we go.

Preparation

First, we need to install the building packages.


| yum groupinstall "Fedora Packager"
| yum install rpmlint yum-utils

Then I created ~/rpmbuild directories and ~/.rpmmacros by using this command.

Steps

First, we need to install the building packages.

| rpmdev-setuptree

* run this command as a regular user

This prepared the package environment for the next steps.


Create RPM package

To create an RPM package, I need to have a ".spec" file that contains infomation about the software being packaged. To generate a default spec file, issue the command rpmdev-newspec "package" under the SPEC directory. Edit the spec file until it compiles without an error. After that, check the spec file, SRPM, and RPM file by rpmlint for any error and warning. These are basic steps for creating an RPM package. For more detailed infomation related to the spec file, building process, and examples, please check the following wiki page.
 => How to create an RPM package

which

I copied the tarball into ~/rpmbuild/SOURCES. The file should be located in the SOURCES directory since the spec file will look for source file in this directory when you build the rpm package.

| cp which-2.20.tar.gz ~/rpmbuild/SOURCES

Create an empty skeleton spec file:

| rpmdev-newspec ~/rpmbuild/SPEC/which.spec

Edit the spec file to include necessary information for building "which" package. Below is my first spec file.


Time to build the package!

| cd ~/rpmbuild/SPEC/
| rpmbuild -ba which.spec


The build was successful! Then I got RPMs and source RPM built in the following directories.

rpmbuild
├── BUILD
│   └── which-2.20

├── BUILDROOT
├── RPMS
│   └── x86_64
│       ├── which-2.20-1.fc17.x86_64.rpm
│       └── which-debuginfo-2.20-1.fc17.x86_64.rpm
├── SOURCES
│   └── which-2.20.tar.gz
├── SPECS
│   └── which.spec
└── SRPMS
    └── which-2.20-1.fc17.src.rpm


The next step was to check if all of my package files can pass the rpmlint test. rpmlint is a tool to check common problems in rpm packages.

I ran rpmlint for the spec file, SRPM file, and two RPMs.

| rpmlint ~/rpmbuild/SPEC/which.spec
| rpmlint ~/rpmbuild/RPMS/x86_64/which-2.20-1.fc.17.x86_64.rpm
| rpmlint ~/rpmbuild/RPMS/x86_64/which-debuginfo-2.20-1.fc.17.x86_64.rpm
| rpmlint ~/rpmbuild/SRPMS/which-2.20-1.fc.17.src.rpm

I got some errors for RPMs.
 


And I did a lot of research on the Internet as well as the Common Rpmlint issues. I added "post" and "preun" sections in my spec file.This time the build went though without an error. Also the rpmlint which.spec and RPM, SRPM tests passed with 0 error and warning.

I still had 5 errors for debuginfo RPM package. I found this fix regarding to "incorrect-fsf-address" error on the wiki site.

"In all cases, upstream should be informed about this. This is the only requirement with respect to this error.

The license file, usually COPYING, must not be patched for legal reasons. Other files can be patched if deemed suitable. The updated GPL 2.0 license (the usual case) with correct address is at GPL-2.0.txt"

So I removed COPYING file in the %doc section of spec file and I still got the same error. The which package uses GPLv3 license and I think the reason for this error is because the COPYING file was not 100% equal to the original license file. So this error wouldn't affect the actual package building process.


hello

Follow the same steps as creating which package. I created "hello.spec" template and edited the spec file. When I tried to build the spec file, I got the following errors. And the build was unsucessful.

error: Installed (but unpackaged) file(s) found:
   /usr/share/locale/bg/LC_MESSAGES/hello.mo
   /usr/share/locale/ca/LC_MESSAGES/hello.mo
   /usr/share/locale/da/LC_MESSAGES/hello.mo
   /usr/share/locale/de/LC_MESSAGES/hello.mo
   /usr/share/locale/el/LC_MESSAGES/hello.mo
   /usr/share/locale/eo/LC_MESSAGES/hello.mo
   /usr/share/locale/es/LC_MESSAGES/hello.mo
   /usr/share/locale/et/LC_MESSAGES/hello.mo
   /usr/share/locale/eu/LC_MESSAGES/hello.mo
   /usr/share/locale/fa/LC_MESSAGES/hello.mo
...........................

...........................
   /usr/share/locale/uk/LC_MESSAGES/hello.mo
   /usr/share/locale/vi/LC_MESSAGES/hello.mo
   /usr/share/locale/zh_CN/LC_MESSAGES/hello.mo
   /usr/share/locale/zh_TW/LC_MESSAGES/hello.mo



Since the unpackaged files seemed like all language files, I added the following lines in the spec file.

%find_lang hello

%files -f hello.lang

Then the build was successful with "exit 0".

Also rpmlint for all four files were passed without errors and warnings.


Done!

Here's the link to all the files I've created in this lab.
=> which package (spec file, RPMs, SRPM)
=> hello package files

Until here my first RPMs have been created. Thanks for reading. :)



Build from Source

Intro...

For this lab, I'm going to install two packages from GNU software collection and check the package build and process. It is also a preparation before I build my first SPEC file for Fedora package.

The packages I've picked are "which" and "hello".

So let me start with the software building environment preparation.

Preparation

1. Install development tools for software building process.


yum groupinstall "Development Tools" "Development Libraries"

 (Note: need to be root to perform yum installs)


2. Download which and hello packages from GNU software collection.

Which => http://carlo17.home.xs4all.nl/which/
Hello => http://www.gnu.org/software/hello/

3. Now we are ready to build our packages!

Building package


- Which is used for locating a program file in the user's path.

- Hello is a simple greeting program.

The following is how I built my packages. First, I unpacked the tarball file by using the following command.

 | tar -xvzf which-2.20.tar.gz


| tar -xvzf hello-2.8.tar.gz

Then I read through the INSTALL file inside each folder for the build instruction. And both of them use make to build. I need to run the configure script which configures the build environment for Fedora 17. Then compile the package by make command, finally use make install to install package.

The following screenshots show successful building results as well as the building time it takes for which and hello package.

| ./configure
* configure the build environment

which: 
hello:


| make

* build the package

which:
hello:



| make install

 * install package



Now the build of two packages are complete. The compilation and building speeds are different based on the the size of the package.

Here is the running output of using which and hello.


Done and done..

Overall the building process is fun. Even though it's more steps to do than simply using "yum install", I can understand the package building better. I didn't get stuck during whole process. But when I choose which GNU package I will install has taken me a long time. In the beginning I choose "dia" which is a drawing program to build. Then I got into a issue for the build environment. I didn't want to install the x window on my fedora since I have very limited disk space for this VM... So I choose the tiny "hello" package to build instead.


My next blog will talk about how to create an RPM package... See you...