I think I got git

I've played around with git for a bit. Instead of using /etc, I used a directory in my user account that had a mixed collection of binary and text files.

First, I setup the git environment:

$ git config --global user.name "Rahi Parsi"
$ git config --global user.email rparsi@learn.senecac.on.ca

Then using the mockresults directory:
$ git init
$ git commit

This is where I first got a little confused. Git displays a text document using vi (or "less", not really sure). I couldn't figure out what to do at first. After some frustration, figured out that I can enter some remarks and just save.

Next I created some text files, created some zip files using the rpm's, and added to git:
$ git add stuff.zip notes.txt
$ git commit

Created a test branch:
$ git branch test
$ git checkout test

Made some changes:
$ rm root.log state.log
$ git commit -a
$ git checkout master

I made more changes by creating directories and adding files. The "vi" like popup screen that shows up after "$ git commit" takes some getting used to. It just feels odd, as I've never used a RCS that behaved like that.

Cleanup:
$ git branch -d experimental

Overall, I like git. It's not that hard to figure out and is quite versatile. Only negative I can say about it, is the "vi" popups for comments. Maybe I'm asking for too much, but I think there's a better approach somewhere.

Signing RPM packages - Done! | Creating a YUM repository - Done!

I created my yum repository on the Ireland system, and then proceeded to have a hell of a time with the gpg key generation. It so long to generate the key, thought it had frozen a few times.

I also tested distcc using the autoconf source package.

My repository is in /var/www/html/rparsi, so the URL would be http://142.204.133.26/rparsi/

It contains all RPM packages, the repo file and the public RSA key.

There's an RPM named "rahiskey" which installs the key and the repository on the system.

Distcc - shaves off 7 minutes

After trying to get gcc to build, have switched to the autoconf package.

Without distcc, it takes approximately 12 minutes to build. With distcc (Scotland as the server) the output is:

real 12m15.636s
user 7m7.141s
sys 5m16.847s

So essentially not much of a difference. I'm a bit surprised, as I expected the overhead of distcc to increase the build time.

Gcc, would you please build -- Thanks

Update regarding build of gcc package:

1. Still haven't solved the build problem. I get the same error message on Scotland, Australia and Ireland, so that rules out a Fedora version issue.

2. Testing with mock produces mixed results. "mock" completes the source and binary build in 121 minutes and 10 seconds. Running rpmlint on the resulting binary packages shows one error regarding glibc-devel.

3. Inspection of the build.log file shows a lot of "Error 1" and "Error 2" entries, which don't seem to be stopping the build.

At this point I'm not sure how to proceed.

Analysis of buildall.log [Scotland machine]

After sorting the buildall.log file created on the Scotland pc, these are the packages that took 1 or more hours to build:

UnihanDb-5.1.0-7.fc10.src.rpm,30428.28,0
openoffice.org-3.0.0-9.10.fc10.src.rpm,13593.51,0
diveintopython-5.4-12.fc9.src.rpm,8074.33,0
gcc-4.3.2-7.src.rpm,6999.26,0
GREYCstoration-2.8-1.fc9.src.rpm,6209.69,0
jgroups-2.2.9.2-4.6.fc10.src.rpm,4371.76,0
paraview-3.4.0-1.fc10.src.rpm,3764.76,0
kernel-2.6.27.5-117.fc10.src.rpm,3679.52,0


This list was derived by first sorting the log file (sort -n -r -t',' -k2 buildall.log), and feeding that output to a custom awk file:

BEGIN{ FS = ","; nMin = 3600;}
{
value = $2 + 0.0;
#print "DEBUG: comparing "value" with "nMin;
if(value >= nMin){ print $0;}
}

Going back to the packages in the list, the first one (UnihanDb) takes about 8 hours. Openoffice takes about 4 hours. Other packages range from 1-3 hours.

Unihan is a normalized character database, used for non-english character sets, variant character research, and input method development. Eight hours still seems too much, but is still realistic/believable.

To 64-bit or not to 64-bit, that is my dilemma

If you're wondering why the loooong gap in blog postings, it's for several reasons, mostly personal.
To put it bluntly, I've been working and going to school non-stop for 2 years without a single break, and the stress of this semester coupled with fatigue, and personal matters, has broken me down.

However, I'm making every possible effort to catch up, and as of March 20 have caught up to my CIS701 and PHP701 classes. More work to be done, for sure.

For SBR600, I'm working on the gcc package. At the moment, I'm almost done installing the build requirements on the "Ireland" machine. One possible problem though, one of the required packages is only available in 64 bit (x86_64 package name suffix). Thus I'm installing 64 bit versions of all the packages, including the 64 bit source rpm for "gcc". At this point, I don't know if gcc can be built using a mix of 32 and 64 bit packages, so I'm trying for an all 64 bit version first.

Will keep you, the reader, up to date on the progress.

Tale of two hard drives

My replacement (SATAII) drive is exhibiting strange behaviour.

I installed Fedora 10, and customized it in exactly the same manner as my remaining IDE drive. The difference?

CUPS works flawlessly on my IDE with SELinux enabled and set to Permissive. On the other, CUPS is being blocked from creating files. I tried "enabling" all of the SAMBA options to no effect. Currently SELinux on that drive has been disabled.

If I ever have time, will investigate this mystery.

Other than that, not much to report on. It's hard for me to blog every week when nothing's really changed.

As for SBR600, last week we (as a class) compiled some packages while measuring system activity.