0.3 Release Items:

Pandaboard Kernel:

• Kernel Configuration File (AoE enabled)
• AoE Kernel Module
• Kernel Source 2.6.35-dirty (w/modules)
• uImage (Kernel)

Documentation:

• AoE Installation & Configuration – http://dliscio.wordpress.com/2011/11/13/ata-over-ethernet-release-0-1/
• Pandaboard Kernel Building – http://dliscio.wordpress.com/2011/11/30/0-2-release/

Links & Resources:

• CDOT hosted: Pandaboard OMAP4 Kernel Source – http://scotland.proximity.on.ca/fedora-arm/kernel/panda/kernel-omap4.tar.gz
• Lastest Pandaboard Kernel/x-loader/u-boot GIT – http://gitorious.org/pandaboard
• Pandaboard WIKI (Kernel Building) – http://elinux.org/PandaBoard
• CDOT: AoE Support – http://zenit.senecac.on.ca/wiki/index.php/AoE_Support
• Sourceforge: Aoetools – http://aoetools.sourceforge.net/
• Freenode IRC Channels: #fedora-arm, #seneca

Part 1 – Download Kernel Source Tree:

This step will download the required kernel tarball to your home directory.

wget http://scotland.proximity.on.ca/fedora-arm/kernel/panda/kernel-omap4.tar.gz

Part 2 – Building the Kernel:

• Unpack the kernel tarball using the tar command.

tar xzvf kernel-omap4.tar.gz

• Change directories to the newly extracted directory.

cd kernel-omap4

My testing and configuration thus far has been between two Fedora 15 machines (laptops), one x86_64 and the other x86 based. I plan on configuring AoE between two Fedora 15 desktop systems to get a better idea of how performance is using AoE on a gigabit LAN network. I will post an update when the desktop configuration is complete.

I have now configured AoE on two x86_64 machines, the updated configuration steps are shown below. The old configuration has been crossed out.

Initial Server/Client Configuration:

• Check the kernel to ensure it supports AoE
• Edit the /etc/rc.local file using vi and add the line below to the end of the file. This will load the AoE kernel module on boot

1. vi /etc/rc.local

modprobe aoe

• Start the AoE module by running the following as a root user

modprobe aoe

Server Configuration:

• Install the Virtual EtherDrive blade daemon package using yum. This will allow for the drives to be exported and available on the network using AoE

yum install vblade

• Create a logical volume using LVM to be used as an AoE block storage device. The -L option is for the size of the volume and the -n is for the name of the logical volume, and beside it the name of the volume group it is located in. The “hk” in this case is the volume group name in LVM.

1. lvm

lvcreate -L20G -n aoe vg_default

lvcreate -L25G -n aoe hk

• Export the newly created volume using vblade.

vbladed 0 1  /dev/vg_default/aoe

vbladed 0 1  em1 /dev/hk/aoe

*Note: The network interface in this example is “em1″. Please replace this value with the primary network adaptor you plan on using with AoE. You can find your interface using the “ifconfig” command from a terminal window.

• Add the same line as above at the end of the /etc/rc.local file

1. vi /etc/rc.local

vbladed 0 1 /dev/vg_default/aoe

vbladed 0 1 em1 /dev/hk/aoe

Client Configuration:

• Install aoetools to connect to storage devices via ethernet

yum install aoetools

• Check for available AoE devices on the network

aoe-discover

• Show available storage devices from recent discovery process

aoe-stat

• Check to ensure that the newly discovered storage device is present on your system

ls /dev/etherd

• Partition the disk using fdisk

fdisk /dev/etherd/e0.1

• Create a new partition:

1. Select option “n” to create a new partition
2. Select “p” for a primary partition
3. Select “Enter” to accept the default values for all remaining options
4. Select “w” to save the changes to the partition table

• There should not be a device called e0.1p1 in the following directory /dev/etherd/

• Create a filesystem on the newly created partition

mkfs.ext4 /dev/etherd/e0.1p1

• Create a folder in the /mnt dirctory for mounting the storage device

mkdir /mnt/aoe

• Change the permissions on the folder to allow for users to read and write to the storage device

chmod 777 /mnt/aoe

• Mount the filesystem for usage

mkdir /mnt/aoe

mount -t ext4 /dev/etherd/e0.1p1 /mnt/aoe

• Check to see that the device was successfully mounted. It should be listed from the output of the following command:

mount | grep aoe

• Add the mount point to the fstab to mount the device on boot

1. vi /etc/fstab
2. Add the following line to the end of the fstab file and save the changes.

        /dev/etherd/e0.1p1     /mnt/aoe     ext4     defaults,_netdev     0 0

• Add the following lines below to the end of the rc.local file to run required commands on boot.

1. vi /etc/rc.local

aoe-discoversleep 5

mount -a

Summary:

The configuration for AoE is fairly simple and straightforward. One can easily have a usable AoE network storage solution up and running in 30 minutes or less. As for performance, I have only been able to test my configuration on my two laptops running on a 10/100Mbps LAN, but through transferring large amounts of data I have yet to see any serious issues such as packet loss or performance slowdowns. I will have an updated post once I configure AoE on two desktop machines running on a gigabit LAN. An update on the actual performance of this new configuration will be posted shortly.

Links:

Howtoforge - AoE Configuration on two Fedora machines

Configuring kernel modules to load at boot (optional method)

Requirements:

- 1 or more RPM packages (for signing)

- Experience with building RPMs

Part 1 – Signing RPM packages

Create a GPG key for your packages. Depending on which version is installed on your system, GPG or GPG2 will be available for the command listed below.

gpg2 –gen-key

Follow the onscreen prompts and select the default options where available. Fill in your real name and email address when requested to.

• Add the email address you entered during the gpg key creation to the %_gpg_name macro in the ~./rpmmacros file
• The line will look like the following:

%_gpg_name “dliscio@learn.senecac.on.ca”

In my case, I will be signing my two RPM packages; units and zile. To sign the RPMs, run the following command:

rpm –addsign units-1.88-100.fc15.x86_64.rpm zile-2.3.24-100.fc15.x86_64.rpm

If you have multiple RPMs located in a single folder that you would like to sign , you can use the “*” to indicate to the “rpm –addsign” command that you want all packages in the folder to be signed.

eg. rpm –addsign ~/rpmbuild/RPMS/*

Part 2 – Create a YUM Repository

For this step, select a location to host your repository. I used my Seneca College HTTP server to host my repository.

• Create the directory structure on your hosted repository, and replicate the exact same setup on your local machine where your packages are located.
• Shown below is how I structured my repository directory:

public_html/
└── dliscio-repo
└── fedora
└── releases
└── 15
└── Everything
├── source
│   └── SRPMS
└── x86_64

When you have finished creating your repo directories, copy your signed RPM files from Part 1 to the appropriate directory. Because my packages were 64-bit, I placed them in the x86_64 directory.

• Create the repository metadata for the recently created repo directory

createrepo ~/public_html/dliscio-repo/fedora

When this is completed, a folder called “repodata” will be placed in the directory.

*Please note* Any changes made to the repo directory such as adding new, signed packages or changing the directory structure requires the “createrepo” command to be run again to update the metadata.

Copy the signed RPMs and repodata to their respective places on your hosted repository. This can be done using the SCP command.

[dliscio@merk]$ scp ~/public_html/dliscio-repo/fedora/releases/15/Everything/x86_64/repodata/* dliscio@matrix:~/public_html/dliscio-repo/fedora/releases/15/Everything/x86_64/repodata/

[dliscio@merk]$ scp ~/public_html/dliscio-repo/fedora/releases/15/Everything/source/SRPMS/repodata/ matrix:~/public_html/dliscio-repo/fedora/releases/15/Everything/source/SRPMS/repodata/

Part 3 – Testing the Repository

To test the recently created repository, we need to create a repository file. For this I used an existing file, the fedora.repo file as a template.

• Create a copy of the fedora.repo file in the /etc/yum.repos.d directory and edit it.

cp /etc/yum.repos.d/fedora.repo /etc/yum.repos.d/dliscio-repo.repo

vi /etc/yum.repos.d/dliscio-repo.repo

Listed below if the configuration of my repository file:

[dliscio-repo]
name=dliscio Fedora $releasever – $basearch
baseurl=http://matrix.senecac.on.ca/~dliscio/dliscio-repo/fedora/releases/$releasever/Everything/$basearch/
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dliscio-fedora-releases

The “baseurl” option matches my hosted repository location and my gpgkey entry matches the location where my gpg key is stored on my local machine.

To create the GPG key, run the following command needs to be run:

gpg –export –armour email@address > ~/RPM-GPG-KEY-dliscio-fedora-releases

Copy the key to the following directory as the ROOT user:

cp /home/dliscio/RPM-GPG-KEY-dliscio-fedora-releases /etc/pki/rpm-gpg/RPM-GPG-KEY-dliscio-fedora-releases

Run a YUM command to test that your repository is working.

[root@merk yum.repos.d]# yum install units zile
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
–> Running transaction check
—> Package units.x86_64 0:1.88-100.fc15 will be installed
—> Package zile.x86_64 0:2.3.24-100.fc15 will be installed
–> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package      Arch          Version                   Repository           Size
================================================================================
Installing:
units        x86_64        1.88-100.fc15             dliscio-repo        134 k
zile         x86_64        2.3.24-100.fc15           dliscio-repo        112 k

• Notice that the “Repository” is labelled, dliscio-repo; this confirms that YUM is checking/using your repository for packages, rather than its own repository during the install process.

Part 4 – Creating a Repository RPM

Creating a repository RPM is a great way to share and enable the use of your repository for others in an easy to install RPM package. This takes the effort out of adding a new repository as the RPM will take care of copying the repo and GPG key to their respective locations.

• Copy your repo and GPG key files to the “SOURCES” folder under your “rpmbuild” directory.

cp /etc/yum.repos.d/dliscio-repo.repo ~/rpmbuild/SOURCES/

cp /etc/pki/rpm-gpg/RPM-GPG-KEY-dliscio-fedora-releases ~/rpmbuild/SOURCES/

• Change to the SPECS directory

cd ~/rpmbuild/SPECS

• Download RPM Fusions repository RPM and install it under your username. This will dump the spec file into the rpmbuild directory without actually installing the program.

http://rpmfusion.org/Configuration

• Rename and edit the spec file. Ensure that the “Source” fields are changed to the names of your yum repo and GPG key files that are in the SOURCES directory. Fill in the rest of the fields with your own information, replacing RPM Fusions data. A sample spec file can be seen below:

Name:        dliscio-repo
Version:    1
Release:    1
Summary:    David Liscio’s Repository Configuration

License:    GPLv3+
URL:        http://matrix.senecac.on.ca/~dliscio
Source1:    dliscio-repo.repo
Source2:    RPM-GPG-KEY-dliscio-fedora-releases
BuildRoot:    %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:    noarch

%description
This is a test repository created by David Liscio.
It is hosting GNU applications that were packaged
by me for my SBR600 course.

%prep

%build

%install
rm -rf $RPM_BUILD_ROOT

# Create dirs
install -d -m755 \
$RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg  \
$RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d

# GPG Key
%{__install} -Dp -m644 \
%{SOURCE2} \
$RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg

# Yum .repo files
%{__install} -p -m644 %{SOURCE1} \
$RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%{_sysconfdir}/pki/rpm-gpg/*
%config(noreplace) %{_sysconfdir}/yum.repos.d/*

%changelog
* Wed Oct 05 2011 David Liscio – 1-1
- Initial build for deliscio-repo

• Build the package once the spec file configuration has been completed

rpmbuild -ba dliscio-repo.spec

• If rpmbuild completed with an exit status of 0 and no errors, test the RPM package with rpmlint.

rpmlint ~/rpmbuild/RPMS/noarch/dliscio-repo-1-1.noarch.rpm

• Copy the repository RPM to your hosted repo for others to install and use.

[dliscio@merk noarch]$ scp dliscio-repo-1-1.noarch.rpm dliscio@matrix:~/public_html/dliscio-repo/fedora/

Summary

Overall, I found that the process for creating a repository to be pretty straight forward. I did run into a few problems with the repodata folder not being placed in the correct directory. I had placed it under dliscio-repo instead of creating a different repodata for each architecture. Running the ”createrepo” command on my x86_64 and SRPMS folder separately seemed to fix the problem. It took a bit of time to get the SPEC file figured out for my repo RPM. Once I understood the layout and process of the RPM Fusion SPEC file template, things fell into place and only required me to change a few fields to get the SPEC file to build my RPM. A link to my repository RPM can be found in the links section below.

Links

My Repository RPM Package: http://matrix.senecac.on.ca/~dliscio/dliscio-repo/fedora/dliscio-repo-1-1.noarch.rpm

RPM Fusion: http://rpmfusion.org/RPM%20Fusion

AoE is simple, yet effective in that there is little overhead as it is runs on data link layer 2, with no TCP/IP protocol required to process the traffic. More info regarding the project can be found at the link below. If you would like to track the progress of the project you can refer to the main project page: http://zenit.senecac.on.ca/wiki/index.php/AoE_Support. If you have experience with AoE on Linux-based systems and would like to offer advice/tips, or have questions, please feel free to contact me.

Part 1 – Installing Mock and Koji

Install both packages using YUM to use Mock and Koji tools for testing.

yum install mock fedora-packager

In order to use Mock to test your RPM packages, you will first need to add your username to the “mock” group.

usermod -G mock dliscio

Part 2 – Using Mock

To test using mock, you will need to have an SRPM. It is easiest if you first change directories to where these SRPMS are located before using mock.

cd /home/dliscio/rpmbuild/SRPMS

To use mock, use the following syntax: mock -r distribution-release-arch SRPMfile

The -r option is for specifying CHROOT and the name of the config file to be used, in this case the default config file is used.

Shown below is an example of using mock to test a package for an i386, fedora 15 based system.

mock -r fedora-15-i386 /home/dliscio/rpmbuild/SRPMS/units-1.88-1.fc15.src.rpm

If you receive errors with your mock build, you can check the following directory for log files:

/var/lib/mock/distribution-release-arch/result

Build Time:

The build time for mock will depend heavily on you internet connection as mock will need to download numerous packages using YUM to test your SRPM. Using mock on campus at Seneca College is extremely fast as there is a local Fedora repository on-site.

• Units: 1m12.304s

• Zile: 1m28.674s

Notes:

Upon first using mock, I ran into an issue an error building one of my packages named zile. The error was related to a failed dependency with ncurses. It was a strange error because I had specified the dependency in the SPEC file and had built the package successfully on my local machine. It turns out that I had forgotten about installing the ncurses-devel package while building my package from source. When creating my RPM I had placed the wrong dependency in the SPEC file, but it still built successfully on my machine because I already had the dependency installed. I fixed the mock error by correcting the SPEC file with the proper dependency, and rebuilt my RPMS. Once I re-ran mock, it built the package successfully.

• Updated Zile SRPM: zile-2.3.24-1.fc15.src.rpm

Part 3 – Building with Koji

To start using Koji you will first need to run the following command to set-up your Koji environment on your local machine. This will run a number of scripts and create certificates which will prepare your local machine for queuing builds to Koji.

fedora-packager-setup

To use the web interface of Fedora-Koji, you will need to add the recently created certificate to your browser, in this case the browser is Firefox.

1. Open Firefox, click edit and select preferences
2. Click the advanced tab, from here select the encryption tab
3. Select view certificates and click the “your certificates” tab
4. Click the import button and navigate to the file that was specified when running the fedora-package-setup command
5. You should now be able to login and authenticate to the Koji web interface: http://koji.fedoraproject.org/koji/

To send a package to the Koji build farm we will be using the koji command with the following syntax: koji build dist-f15 –scratch SRPMfile

*It is important to include the “–scratch” option when queuing your SRPM for testing to ensure that the build is not committed to the fedora distribution.*

I used the following commands to queue and build my two packages in koji:

koji build dist-f15 –scratch /home/dliscio/rpmbuild/SRPMS/units-1.88-1.fc15.src.rpm

koji build dist-f15 –scratch /home/dliscio/rpmbuild/SRPMS/zile-2.3.24-1.fc15.src.rpm

You can view the status of a Koji build at any time by using one of two methods.

1. View the task through the Koji web interface by selecting the “Tasks” tab and filtering results by username: http://koji.fedoraproject.org/koji/index
2. Run the following command from a terminal window:

koji watch-task taskID

Build Time:

This will depend on how much load is currently on the hosts you are building on. Your package will be queued until there is enough capacity to process your build.

• Units: 7 minutes

• Zile: 3 minutes

Summary:

Overall, I had little to no issues using Mock and Koji in testing and building my source RPMS. Mock is a great tool for testing dependencies of a recently built package. It will attempt to build your package by using the packages listed in your SRPMs BuildRequires field as well as include only basic tools that would normally come pre-installed on a Linux system. This ensures that your RPM package has had its dependencies set properly so that it will install correctly on machines other than your own. In my case, Mock found a build dependency that was missing from my SRPM which allowed me to correct the issue, and re-build the package for usage.

As a first-timer dealing with Koji, it was an interesting process uploading and queuing my SRPMs to the build farm. Once Koji was configured on my machine, it was fairly easy to queue my packages for being built and it was even easier to view and track the progress of the build. I had no trouble finding error logs when needed and also had no issues with navigating the Koji web interface, which is organized in a simple and intuitive way. Posted below are links that I found useful during my usage and configuration of Mock and Koji.

Resources:

• Using Mock to test package builds – FedoraProject

• Using the Koji build system – FedoraProject

• Preparing the build environment
• Create default SPEC file/edit SPEC file
• Build RPM package
• Testing the SPEC, RPM, debuginfo RPM, and SRPM files

*Please Note* – This guide assumes that you already have the source tarball for “units” and “zile” already downloaded. Please refer to the Building from Source post for links and descriptions of the applications used here.

Part 1 – Prepare the build environment

To begin the process of building RPMs, we first need to install the Fedora Packager, rpmlint, and yum-utils packages.

su -

(enter root password)

yum groupinstall “Fedora Packager”

When complete, run the following command (as root user) to install the remaining packages:

yum install rpmlint yum-utils

Change back to your regular user account and create the default rpmbuild directories by running the following command:

exit

rpmdev-setuptree

Once the above command is completed, you should have a folder structure in your home directory that looks like this:

[dliscio@merk ~]$ tree rpmbuild/
rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
├── SPECS
└── SRPMS

Copy the source tarball for “units” and “zile” to the ~/rpmbuild/SOURCES directory.

cp ~/Downloads/units-1.88.tar.gz zile-2.3.24.tar.gz ~/rpmbuild/SOURCES

Part 2 – Create and edit the Spec file

The next step in packaging an RPM is to create a default SPEC file. The SPEC file contains info such as the name, version, revision, summary and dependencies or requirements of the application. A SPEC file dictates how a package will be configured, what will be installed, the location of the install, and tasks that the system will need to complete pre and post install.

Change to the SPECS directory.

cd ~/rpmbuild/SPECS

Create the default SPEC files.

rpmbuild-newspec units

rpmbuild-newspec units

Edit the SPEC file using your preferred text editor, filling in all fields. If a field is not required, comment it out using the “#” character.

vi units.spec

vi zile.spec

Units SPEC file:

For this SPEC file, I ran into a few issues regarding a number of files not being copied to their proper locations during the build. The error was as shown below:

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/bin/units
/usr/share/info/units.info.gz
/usr/share/man/man1/units.1.gz
/usr/share/units.dat

I fixed this error by editing SPEC file with the following entries.

BuildRequires:        gettext
Requires(post):        info
Requires(preun):    info

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
rm -f %{buildroot}/%{_infodir}/dir

%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :

%preun
if [ $1 = 0 ] ; then
/sbin/install-info –delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

%files
%doc README NEWS ChangeLog COPYING INSTALL
%{_bindir}/*
%{_mandir}/man1/*
%{_infodir}/%{name}.info.gz
%{_datadir}/%{name}.dat

I added to the %doc entry, files from the extracted tarball that looked like documentation files. For the info.gz file, more steps were required which is why you see the build dependencies listed as “gettext” and the post and preun requires fields filled in with “info”

Zile SPEC file:

This SPEC file did not contain an info.gz file, but did require the addition of filenames to the %files section.

%files
%doc
%{_bindir}/*
%{_mandir}/man1/*
%{_datadir}/%{name}/FAQ
%{_datadir}/%{name}/dotzile-extra.el

Save your SPEC files when you have finished editing them and continue to part 3.

Part 3 – Build the RPM package

To build an RPM package, the command “rpmbuild -ba specfile.spec” is used. The -ba option tells rpmbuild to build the source and RPM packages from the specfile specified.

Attempt to build the RPM package:

rpmbuild -ba units.spec

rpmbuild -ba zile.spec

After running the build, fix any errors that may occur. The last few lines of a successful build for units is shown below as an example.

Wrote: /home/dliscio/rpmbuild/SRPMS/units-1.88-1.fc15.src.rpm
Wrote: /home/dliscio/rpmbuild/RPMS/x86_64/units-1.88-1.fc15.x86_64.rpm
Wrote: /home/dliscio/rpmbuild/RPMS/x86_64/units-debuginfo-1.88-1.fc15.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.PhVm9O
+ umask 022
+ cd /home/dliscio/rpmbuild/BUILD
+ cd units-1.88
+ /bin/rm -rf /home/dliscio/rpmbuild/BUILDROOT/units-1.88-1.fc15.x86_64
+ exit 0

If the build completes with an exit status of 0 without errors, continue to part 4 for testing.

Part 4 – Testing using rpmlint

Now that you have built an RPM package, we need to test the package for errors using a tool called rpmlint.

Run  rpmlint on each of your SPEC, RPM, debuginfo RPM, and SRPM files to ensure that they do not contain errros.

Units:

[dliscio@merk SPECS]$ rpmlint units.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

[dliscio@merk SPECS]$ rpmlint ../RPMS/x86_64/units-1.88-1.fc15.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

[dliscio@merk SPECS]$ rpmlint ../RPMS/x86_64/units-debuginfo-1.88-1.fc15.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

[dliscio@merk SPECS]$ rpmlint ../SRPMS/units-1.88-1.fc15.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Zile:

[dliscio@merk SPECS]$ rpmlint zile.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

[dliscio@merk SPECS]$ rpmlint ../RPMS/x86_64/zile-2.3.24-1.fc15.x86_64.rpm
zile.x86_64: W: name-repeated-in-summary C Zile
zile.x86_64: W: spelling-error %description -l en_US customizable -> customization
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

[dliscio@merk SPECS]$ rpmlint ../RPMS/x86_64/zile-debuginfo-2.3.24-1.fc15.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

[dliscio@merk SPECS]$ rpmlint ../SRPMS/zile-2.3.24-1.fc15.src.rpm
zile.src: W: name-repeated-in-summary C Zile
zile.src: W: spelling-error %description -l en_US customizable -> customization
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

The warnings marked by a W for the zile files are not critical items, but rather recommendations in this case for a repeat name in the summary field and a “spelling” error in the description (not actually an error). Warnings will not cause your package to be unusable, but if you start seeing many warnings when checking with rpmlint, you should further analyze the warnings to ensure that no major problems are occurring behind the scenes.

Summary

This is a basic overview of the build process for packaging an RPM file from source. There is plenty of documentation available online for a more in-depth look into SPEC files and what you can do with each field in the file. I will post links to the files I created during the build process in the links section below. I will also provide links to a few websites I found useful while working through the build process that may help you in configuring the SPEC file for other packages.

Links

• RPMBUILD Directory w/SPEC, RPM, debug RPM, and SRPM for units and zile
• FedoraProject - How to create an RPM package
• FedoraProject – How to create a GNU Hello RPM package
• Open Source @ Seneca – RPM spec File Contents

*Please Note* – I will show the build process for “units” specifically, but the same process can also be used for building Zile and most other applications from source code.

Part 1 – Download the Source Code

Download the source code in tarball form from the following location:

http://ftp.gnu.org/gnu/units/units-1.88.tar.gz

Save the file to a known location on your machine. In my example I will be working in my Downloads directory (replace with your own dir).

Change to the Downloads folder using the change directory command.

cd /home/dliscio/Downloads

Part 2 – Extract the Tarball

Extract the tarball that was recently downloaded using the tar command and use the following options (in order): e(x)tract, (v)erbose, g(z)ip, and (f)ile

tar -xvzf units-1.88.tar.gz

Change directories again to the newly extracted directory in the Downloads folder called “units-1.88″.

cd units-1.88

Part 3 – Install the Application

./configure

[dliscio@merk units-1.88]$ ./configure
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… no

…

configure: creating ./config.status
config.status: creating Makefile

[dliscio@merk units-1.88]$

make

su -

cd /home/dliscio/Downloads/units-1.88

make install

[dliscio@merk units-1.88]$ units
2526 units, 72 prefixes, 56 nonlinear units

You have: 1 litre
You want: 1 quart
* 1.0566882
/ 0.94635295

A little bit about myself; I enjoy biking, gaming (I’m a noob), computers, and eating (Korean BBQ). In my spare time I enjoy following/testing android ROMS and kernel development, as well as testing and using open source products such as the Tomato Firmware for consumer routers and FreeNAS for NAS storage.

As a part of SBR600, I was asked to post a portion of IRC chat with another member in the Seneca IRC channel: freenode#seneca. Posted below is a portion of the chat with user jjmiller:

<jjmiller> hey
you in sbr600?…the same miller i’m thinking of?
<jjmiller> indeed
o ok…it’s david from ING….you ok if i put some random talk in my blog?
<jjmiller> lol no worries
<dliscio> hah alright cool, thanks

That is all for now, aside from this blog you can also find me at the links listed below:

• Seneca Wiki – http://zenit.senecac.on.ca/wiki/index.php/User:Dliscio

• Fedora Wiki – https://fedoraproject.org/wiki/User:Dliscio