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.

Hard drive dead

Well, it was bound to happen. My old IDE hard drive from way back (actually, 2nd semester) died today. I'm currently updating and customizing Fedora 10.

Will have to complete the process next week (Feb.9).

Here's hoping my remaining IDE drive lasts for the rest of the semester!

New prm created from cups-pdf

Using the cups-pdf package, I modified the original source code to attempt dynamic output directory usage. So far it hasn't worked.

However, the source and binary do build using rpmbuild -ba.
Testing the source and binary rpm's using rpmlint produces 2 error messages regarding file permissions. I downloaded the official source rpm and tested with rpmlint, getting the exact same error message.

Testing with "mock" worked, as the binary rpm did build from the source.

Made my first RPM

Took a long time.

First I tried using a template Spec file, but "rpmbuild" failed on "Source0". After considerable reading, troubleshooting and pondering, figured out the right URL format to allow download of source from the SourceForge site.

Then I was stuck in the middle of the %prep stage. Rpmbuild was trying to change the working directory to something based on the versioning scheme I used. However, since the original source uses a different version number, the build would stop. Once I used the same version number as the source, it worked.

The source RPM is here:filezilla-3.1.5.1-1.fc10.src.rpm