Status for Andrew DeFaria

• Attempted to build LOS178 TOT which is failing
• Attempted to build LOS 178 TOT for Linux cross. Also failing
• Updated FCS ICS Hybrid OS Build Procedure document

Posted by at 5:45 PM | Permalink

• Implemented many improvements to cvs_report.pl
• Implemented some improvements to cvsr.php
• Re-performed steps 1, 8-12 of BC build in order to pickup changes to tests and demos. Made new images available at ftp://saturn.

CVS Report Improvements

Main problem addressed is that certain ECRs (or CRs) would show up if they were imported from a vendor branch. In general handling of revisions on branchs were not working very well. Other improvements include:

• Changed to use Display package
• While cvs_report.pl tries to avoid doing cvs update or recreating the cvs area it is possible that tags could move thus cvs_report.pl should refresh the cvs area in case the baseline tag has moved.
• The special tag HEAD is ill defined under CVS. If a file is branched and the baseline tag is on the branch then it turns out that HEAD means the branch's head (this is with cvs diff only). If the file's baseline tag is on the trunk then HEAD means the trunk's head. Additionally the special revision 1.1.1 means vendor branch and is an alias for 1.1. This special situation is now better handled.
• Changed the cvs diff --brief to use both from and to tags. Initially it was thought that if from tag didn't exist then cvs diff would complain about that. It does - sometimes. Ah the consistancy of cvs! Gotta love it! Still it's thought that it's better (clearer) to specify both from and to tags
• Detection of no change is now better handled

cvsr.php Improvements

• Now properly reports the latest revision when multiple revisions are checked in for the same ECR
• Changed to return 2 character status, one indicating if the file is new and one to indicate if the file has changed (since the last report). This allows us to have a new and changed file.

Posted by at 12:36 PM | Permalink

Wrote the following to Sasha today:

I'm still trying to build BC on RH 8.0. Since I was successful at building BC 5.3 on RH 6.1 I figured I oughta try building BC 5.3 on RH 8.0. I am also building starting as root.

I've tried twice now and it continues to fail in step 4.1 building the kernel. The following appears in build_kernel.log:

+ echo BUILDING A KERNEL FOR pmac_g5...
+ cp /build/bluecat/build/20050429/cdt/src/bluecat/SOURCES/bluecat-pmac_g5.config arch/ppc/defconfig
+ rm -f .config
+ make mrproper
+ make oldconfig
/bin/sh: line 1: bc_native_gcc: command not found
make[1]: *** [scripts/basic/fixdep] Error 127
make: *** [scripts_basic] Error 2
error: Bad exit status from /build/bluecat/build/20050429/var/tmp/rpm-tmp.94728 (%build)
    Bad exit status from /build/bluecat/build/20050429/var/tmp/rpm-tmp.94728 (%build)

Apparently var/tmp/rpm-tmp.94728 is a build script built on the fly then executed. bc_native_gcc does exist in /usr/src/bluecat/eng/bluecat/bc_misc but this script can't find it.

Ideas?

Posted by at 9:22 AM | Permalink

The more I look into CVS the less I understand. Perhaps you can help me...

For the file los178/sys/kernel/getmem.c I see the following:

saturn:cvs log getmem.c

RCS file: /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
Working file: getmem.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
       DEV_LOS178_2p1p0_ppc_20050503: 1.1.1.1.2.1
       REL_LOS178_2p0p0-branch: 1.1.1.1.0.4
                 ...
       REL_LOS178RSC_2p0p0_ppc_FCS: 1.1.1.1
                 ...
saturn:cvs st getmem.c
===================================================================
File: getmem.c          Status: Up-to-date

  Working revision:    1.1.1.1
  Repository revision: 1.1.1.1 /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
  Sticky Tag:          REL_LOS178_2p0p0_ppc_FCS (revision: 1.1.1.1)
  Sticky Date:         (none)
  Sticky Options:      -ko

In particular here notice that head says 1.2 but the current working revision is 1.1.1.1. The CVS Report does a:

saturn:cvs diff --brief -r HEAD getmem.c
saturn:

Does this mean that there is no difference between 1.1.1.1 and 1.2?!? However if I do:

saturn:cvs diff --brief -r 1.2 getmem.c
Index: getmem.c
===================================================================
RCS file: /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
retrieving revision 1.2
retrieving revision 1.1.1.1
diff --brief -r1.2 -r1.1.1.1
Files /tmp/cvsvGa4M1 and /tmp/cvswGa4M1 differ
saturn:

Why is this so? Doesn't -r HEAD mean 1.2 in this instance?

Posted by at 2:59 PM | Permalink