Mock and Koji

For this lab we were given the task of using Mock and Koji to test and resolve the dependencies from our RPM that we created in the previous lab.


Mock is a vital tool that’s used for resolving dependency requirements for packages.  Mock creates a sandbox environment where it isolates the RPM.  That way the RPM can be tested with no interference from any outside packages.  This tool is essential in the RPM build process.


Koji is similar to mock with a few more features.  Koji has full web interface where users can see their package’s current status and whether it passed or failed within the build system.

When installing Koji a certificate is generated making Koji extremely secure.  Only Fedora packagers are granted the certificate.  If you were to try to manually generate a certificate then you’d have some difficulty in doing so.  Below is a screen shot of what the Koji interface looks like.

When submitting a job to Koji just enter the following command:

koji build dist-f15 --scratch yourSRPM

After this command has been entered you will be notified if the build is either successful or unsuccessful.  Once this build is successful then you can loin to Koji to view the state of your build.  Below is a screenshot of my build in Koji.

 Overall Experience

At first using these tools was very difficult to understand the process of how everything worked.  It took a lot of troubleshooting and error checking to understand the concept of Mock.  I learned that the Spec file has to have all of the required dependencies order for the build to work.

Koji also took some time to understand as well.  At first I had problems importing my certificate but after generating a new one it imported successfully.  What I like about Koji is that its a practical tool that you can check in real time what the status of your package is.  I find Koji very interesting and I would like to learn more about it in the near future.


RPM Wiriting

After some extensive troubleshooting I was finally able to successfully build an RPM package from the source RPM.  I tried several packages when doing this lab but the only one that seemed successful was gzip, an open source package compressor and archiver.

When building the package I quickly learned that much of the program is written in the spec file and if some of the required files aren’t in the spec file then the RPM package wont build. Below is a screenshot of my gzip spec file:

Below is a link to my source RPMs:


Building Software from Source Code

For the Building Software from Source Code lab I chose the text editor Nano because it is a useful program that I’ll actually use. Below is a screen shot of the tarball that was downloaded.

After the Tarball was installed, I decompressed it using the command tar xvzf nano-2.2.6.tar.gz below is the output of that command:

After the decompression, I ran the ./configure script inside of the extracted directory to configure Nano with all of my current settings.  Below is the output when running the script:

Once the package had been configured, I ran the make command to install Nano on my system.

To ensure that Nano was installed, I ran the program and entered some sample text.

This is a basic example of installing software from the source code. This process was pretty simple and it only took about 5 minutes to complete. Below is link to the Nano website:

SBR – Introduction

Hey Everyone,
My name is Jordan Huestis and I’m in my final semester at Seneca. I’m looking forward toward SBR and the opportunity that it allows us to create and develop products that are actually being used in the real world today. I’m also looking forward to collaborating with everyone that works on the Fedora project on a day to day basis!
Below is my contact information:
IRC Nickname: jbhuestis
Seneca Wiki: Jordan Huestis
Seneca Wiki: My Seneca Wiki
Fedora Wiki: My Fedora Wiki