Tuesday, November 24, 2009

Re-Packaging Dehydra

During our class today, we were testing out the packages we created for our project. And sadly for me, my package failed during the yum install process.

So, I had to start from scratch again. The error I was getting was concerning SpiderMonkey. When I looked at David Humphrey Build-tools.sh script again, I did notice it was compiling SpiderMonkey from a tarball, but my spec file only copied certain files from the tarball, so I guess that is where my error was.

I did some more research into SpiderMonkey, because my professor did mention that Fedora had a SpiderMonkey package, and I soon found out that the package name was "js" and the libraries were in the package "js-devel"

I edited my spec file, removed one of the sources that grabs the JS tarball from Mozilla, and instead for the BuildRequires I put in js and js-devel.

Here is my updated spec file: Here

I went ahead, and rebuilt the rpms on
Germany an i386 architecture machine and HongKong a x86_64 architecture machine

And again they both build with no errors, hopefully on our next trial run the package would install properly.


Here is a screenshot of the successful

Thursday, November 19, 2009

Packaging Dehydra Part2

From my last post, I packaged up Dehydra for the next Fedora 13 release.

After packaging Dehydra up, I noticed I only packaged it up for the x86_64 architecture because I was building it on HongKong which was running Fedora 11 running on the x86_64 release.

Because of this I asked my professor, if there was an i386 CDOT Development System I can use to create the Dehydra package for the i386 machines. He told me that Germany was running on a i386 build, so he created me an account and off I went to create the package.

I use the same spec file I originally used to build the x86_64 package, and in a matter of minutes three i386 rpm files were successfully created.

The RPM Files Can Be Found Here: Project Repo

Tuesday, November 17, 2009

Packaging Dehydra

For Our Class Project, my task was to package up Dehydra and have it ready for the next Fedora 13 release.

Since there is no current Dehydra package for Fedora, I had to create a SPEC file from scratch.
From what I had learned before, I ran the follow command: rpmdev-newspec dehydra
and that created me a empty spec template I can work on for dehydra.

Here is a copy of my spec file: SPEC

Since my project is sort of connected to my colleagues work, I had to hard code some tools into my spec file until he has completed his project.

Throughout the process of creating and building the spec file, I would encounter missing files the configuration file Dehydra was looking for from SpiderMonkey. So I asked my Professor Chris about it, he advised me to look for the files and then just create a symbolic link to where the build file is looking for.

Next issue was, for the %install section because I was not installing anything I left that section empty. But Chris advised me, to create a directory to put the dehydra plugin as right now, there is really no specific directory.

He advised me to follow what he has done with nLed in terms of how he setup the %install portion.


After all the work, I finally completed my task at hand, and came out with the RPMS.

Here are my alpha products of Dehydra, next comes the testing phase
Dehydra RPM: FILE
Debug Dehydra RPM: File

Monday, November 16, 2009

Using Modifed G++ and C++ to Build

Two weeks ago, we were given the task to build a package using a modified version of G++ and C++. The purpose of this tasks is to see if there would be a significant time delay or increase building with the modified g++/c++ tools compared to building with the regular g++/c++ tools.

So, in order to build the packages with the modified G++ and C++, we require a script David Humphrey a professor at Seneca created. The script can be found here

The Package that everyone is using is Abiword.

So, first we download the source rpm for abiword by issuing the following command
yumdownload --source abiword

once downloaded, issue the following command rpmdev-steuptree if you do not have the rpmbuild.

Finally run this command to install the Source RPM and extract the spec file.
rpm -i "package name"

For this task, I created two scripts, one script is for building with the Generic C++/C++ and the other one is for the modified G++/C++. These scripts will basically rename the G++/C++ file, create symbolic links, run the rpmbuild command 3 times and finally log the time it takes to run the build.

Here are the two script I used:
Generic G++/C++
Modified G++/C++


When building with the regular G++/C++ it flew by quickly with no errors, but when it came to modified g++ / c++ I like everyone else was coming into issues with it failing at the install section. As one of my fellow colleague Adam Hilts stated to bypass this problem was to add the following string QA_RPATHS=$[ 0x003f ] to your rpmbuild line.
So in the end my line looked like this in my script
time -o modified.log -a QA_RPATHS=$[ 0x003f ] rpmbuild -ba abiword.spec >/dev/null 2>&1
and success everything was rolling smoothly.

The overall outcome was really not that significant, it did shave some time off a little maybe a 5% increase using the modified version of g++ and c++.

Here Are My Out Comes


Non-Modified Modified
Run Time Real-User-System Real-User-System
1 208.23-205.81-127.99 198.28-196.82-126.28
2 207.97-206.03-128.07 200.82.198.89.127.76
3 211.03-205.86-128.37 199.19-197.30-127.98

Modified G++/C++ Error With Coin2 Package

Trying to stay off the bandwagon in terms of using the modified g++ / c++ to build Abiword like the rest of my class, I set a challenge to work on another package with an ample amout of C++ codes.

I used a script my Professor Chris Tyler had, that would would through a list of Fedora packages and basically exmaines each one and counts how many c / c++ codes there are.

Here is the script I used: FILE
Here is the script to get the modifed g++/c++: FILE (takes about 1 hour to compile)
So the package I decided to work on was Coin2

I was successfully able to build Coin2 without the modified g++ and c++

Command Issue: time rpmbuild -ba Coin2.spec

Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/bchao/rpmbuild/BUILDROOT/Coin2-2.5.0-5.fc11.x86_64
Wrote: /home/bchao/rpmbuild/SRPMS/Coin2-2.5.0-5.fc11.src.rpm
Wrote: /home/bchao/rpmbuild/RPMS/x86_64/Coin2-2.5.0-5.fc11.x86_64.rpm
Wrote: /home/bchao/rpmbuild/RPMS/x86_64/Coin2-devel-2.5.0-5.fc11.x86_64.rpm
Wrote: /home/bchao/rpmbuild/RPMS/x86_64/Coin2-debuginfo-2.5.0-5.fc11.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.yINAzy
+ umask 022
+ cd /home/bchao/rpmbuild/BUILD
+ cd Coin-2.5.0
+ rm -rf /home/bchao/rpmbuild/BUILDROOT/Coin2-2.5.0-5.fc11.x86_64
+ exit 0

real 3m42.609s
user 2m49.487s
sys 2m53.814s


When trying to build with the modifed g++ and c++ I ran into the following problem.

Command Issued: time rpmbuild -ba Coin2.spec

Output:
extracting debug info from /home/bchao/rpmbuild/BUILDROOT/Coin2-2.5.0-5.fc11.x86_64/usr/lib64/libCoin.so.40.5.0
*** ERROR: No build ID note found in /home/bchao/rpmbuild/BUILDROOT/Coin2-2.5.0-5.fc11.x86_64/usr/lib64/libCoin.so.40.5.0
error: Bad exit status from /var/tmp/rpm-tmp.JARMMn (%install)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.JARMMn (%install)

real 2m44.161s
user 2m17.568s
sys 2m24.901s


I'm not sure why I got this issue, but my Professor Chris Tyler will look into this for sure as he said that this will hinder alot of what we are doing. Other than this setback of trying to stay away from the bandwagon, I will blog about my success results with abiword instead.

Tuesday, November 3, 2009

FSOSS 2009

The week of October 26 - October 30 2009, Toronto hosted the event Toronto Open Source Week 2009. For Seneca they hosted their Free Software and Open Source Symposium.



Volunteer - Bag Stuffing
On Tuesday, I expected to come in like last year and stuff bags with T-Shirts, flyers, and Ubuntu CDs, but unexpectedly I was sent on a wild goose chase looking for bags for the speakers as we ran out of them while bag stuffing. It was quite an adventure as I called in many times to find out what kind of bags they wanted. After coming back, we finished stuffing the guest bags, and tearing about the name tags. It was a very interested session.



Presentations Attended On Friday


Beth Agnew - Professor, Co-ordinator of the Seneca Tech Comm Program, Seneca College
The Fourth Dimension -- Documentation that Enhances the User Experience


Christopher Kulbakas - Graduate Student, McMaster University
Formal Modeling of Linux-PAM Authentication Processes

The lunch was phenominal as we had Salad and Cannelloni, way better than the cafeteria food.

The presenations were very informative as Beth Angew taught us how to write a technical paper, and Christopher Kulbakas talked about PAM and his tool he has created.

Overall my experience from the FSOSS was fun and informative.