Build notes LW/GD and tst
- Caught up on build notes for 20050425, 20050519 and 20050525 for LW LOS178
- Resolved CR 41
- Tagged tst's for LW LOS178
- Assisted Adisak with lists for CRs 536 and 584
« April 2005 | Main | June 2005 »
The cvs_report script determines what has changed by using cvs update, just like the old one. But it uses -n to not actually update the area. If it did actually update it then it would have to downdate it (for lack of a better term) for the next night's run. But there is a side effect to not doing the actual update: If there is a new directory the -n will prevent cvs update from looking into what's in the new directory! I did not know this.
This effects CR #570 and possibly others. CR #570 adds a new directory under src/lib/libm called complex with 52 new files. These files did not get included in the list of files to port over.
Additionally cvs_report had an error in a regex such that it was not identifying these new files properly. This has also been fixed.
Both files4ecr and files4cr will suffer this same problem. Let's say we had an E/CR with 10 files modified. If at some later time one of these 10 files is changed, or another file modified with this same E/CR number it will show up in the CVS Report as only that one file modified since the CVS Report goes from some base tag to some other tag (e.g. head). The difference between those tags is only that one file - rightfully so.
However both files4ecr and files4cr work off of the E/CR number identifying all files associated with that E/CR number, irrespective of any other tags that they might have. So the files4cr in the above scenario would pick up all 11 files!
Now according to CVS a commit command should not commit files that have not been modified. The question is what does CVS use to determine that a file has been modified? Contents modified or just say date/timestamp modified? It appears that it's content modified
Still this makes files4[e]cr not very efficient. For example, CR #542 consists of ~3200 files that were modified. Since the last dev build 17 more files were modified. But files4cr picks up ~3200 files! If we are to transfer these over to GD then commit that seems like a large waste of effort
Regarding the openssl problems: With the inclusion of the new TCP/IP stack comes openssl. When building on GD we experienced a problem where when building openssl it tries to regenerate certs. Since some parts of openssl use absolute pathnames and since Tomcat had a /usr/local/ssl directory we theorized that due to the existence of that directory the build of openssl tried to regenerate certs. Since the new certs were not required and were not functionality we said that that error was of no consiquence.
Turns out that what it really happening is that the openssl portion of the build will try to regenerate certs regardless of the presence of /usr/local/ssl and it does so by executing src/net/openssl-0.9.6/apps/openssl. This file is a Linux binary so building on Solaris causes errors. This explains why I keep seeing this as I am building on Rock and Vinnie doesn't see this since he is building on a Linux system.
Later Vinnie points out:
Here is what is happening the apps/openssl is actually a los178 binary which we build & install in $(ENV_PREFIX)/usr/ssl/bin, but is being executed to generate the certificates on a Solaris or Linux host which is not going to work. The problem is happening on both host except on linux the error is different and our check script does not have that error message in the list. We need to update the script to capture the linux error string.
On linux host the error is:
": cannot execute binary file"On Solaris host the error is
": syntax error at line 1: `(' unexpected"File a CR for this problem and maybe suggest the two option below.
There are two options to fix this issue:
- Disable generating the certificates in the Makefile since the pre-generated certificates files are checked-in/available, but these files needs to be installed in usr/ssl/certs
- Generate the certificates, but the appropriate openssl should be installed in the host system & pass the openssl path to the Makefile command.
I've done a little work on trying to come up with more generic scripts that can be used across build machines or indeed the organization. Specifically I've been targeting things like packaging and checking. My scripting language of choice is Perl.
All scripts are relative to my machine at present at saturn:/int. You are free to mount this file system from my machine to your machine to check out the code. In the future I plan on putting this all into a cvs repository and making if available to all who want/need it via a global file system such that adding /int/bin and perhaps /int/adm/bin to one's PATH is all that is needed to gain access to these scripts on any machine. Details of this will be forthcoming in another email.
In this message I will only describe the check and package scripts. Other scripts, including such things as cvs_report, ecrc as well as web pages and scripts will eventually be documented probably through a series of web pages.
Jas had asked me to enhance the checking of install.logs so as to keep track of the growing number of warnings. The check script does this. It will check for errors using the common error strings of other check like scripts as well as warning and optionally issue a total number of errors and warnings. The check script is in /int/bin/check. Here's a short usage:
Usage: check [-u] [-v] [-d] [-t] [-w]
Where:
-u Display usage
-v Turn on verbose mode
-d Turn on debug mode
-t Display total line
-w Include warnings
One or more log files to check
With no options except logfile(s) check will output nothing but set the return status to the number of errors encountered. This allows future script to be able to use this in their script and just check the return status.
Package script
The idea here is to separate the definition of a package from the packaging code itself. The hope is to hand the package definition over to the developers themselves so that they can maintain that - after all they know better what goes where than we do.
Packaging is implemented as a module, specifically a Perl module and as a Perl object itself. The idea is to encapsulate what can be done with a package into an object. The object module is at /int/lib/LWPackage.pm. The "LW" stands for "LynuxWorks". An LWPackage object currently has 3 methods: new, list and package. The new method is called to create a new package object. One parameter must be specified, that being a pathname to a package spec file. That package spec file is parsed and the package object is populated. The list method will list all of the information about the package including the file list. Finally the package method produces the package image itself.
Here is a small Perl snippet that utilizes the LWPackage methods:
my $pkg = LWPackage->new (spec => $spec);
$pkg->list if get_verbose;
$pkg->package;
In fact that's the main code for /int/bin/package, the packaging script. It creates a new LWPackage using the filename in $spec, calls the list method if verbose is turned on (get_verbose is part of the Display package) then calls the package method to create the package image.
Package spec file
Package spec files are denoted by the .lwp extension convention. The format of the spec file is pretty simple. As usual "#" indicate comments, etc. Look at /int/spec/* for example files. Basically the format is similar to:
Name: int
Version: 1.0
ProductNbr: 1000
Release: 00
Base: /int
Fileset:
*
-data
EndFileset
Name, ProductNbr, etc. are used in the creation of the image file name ($ProductNbr-$Release.$Name.$Version.tar.gz). The Fileset section defines the file sets included in the package relative to Base. An "*" denotes the usual connotation of "everything". Other path names could be listed one by one. For example, I could have:
Fileset:
adm
bin
spec
-data
-web
EndFileset
A minus sign does what you'd think - remove files denoted by this. So the above says, "everything under $Base except everything under $Base/data".
As for Fileset lines you can list multiple lines and they are processed in the order that they are entered. Duplicate filenames are removed and the Fileset list is ultimately sorted. You can list either directory names for whole directories (that are recursively processed) or individual file pathnames. Regex's are not supported (yet but should be).
The idea of a package spec is to define the Fileset from where they stand thus eliminating the need to copy large quantities of data into an alternate area so that that alternate area is "clean". IOW it should be able to pull only those necessary files from even a CVS or build tree directly. To that extend future arrangement of things into distinct areas will make writing packaging specs easier.
A plan for /int
We are seeking an NFS mountable global area where we can place various tools and scripts that will help us do our job. A previous email about the check and packaging scripts are an example of this. The basic idea is to be able to mount a global file system area to a short named path on the local system so that scripts like package and check, etc are accessible and readily available when needed.
So, for example, if t3:/export/int were that globally accessible file system one would mount t3:/export/int /int and then add /int/bin and perhaps /int/adm/bin to their path and these scripts would be available.
As these scripts will be used in business processes they are as valuable as our products themselves and thus should be placed under CVS. Let's assume that t3:/cvs/int-cvs were the CVS repository for these scripts. We could check out and modify our own scripts as we further develop them. A nightly cronjob could be set up to cvs export -r >RELTAG< /export/int to make sure that /export/int reflects where >RELTAG< is some release tag. Then people could check out and enhance/modify our scripts in a test like environment and when "released" simply move the >RELTAG< to the committed version. The updated version would be available the next day (or we could force it by hand if necessary).
As for what gets put into /int I see the following directory structure:
adm: Administrative area
bin: Administrative bin scripts
data: Any adm data files that you might need
etc: Rough equivalent of /etc
functions: bash script functions (currently symlinked to ../functions)
bin: Scripts and apps for int
data: Any data you might want
functions: bash script functions
lib: For Perl and other library modules
spec: Spec files (may get rid of this)
test: Any test scripts. For example, test script to test the functionality of the modules in ../lib
web: Might want to move this elsewhere. Basically a replica of the web pages and scripts I've been doing (so as to have a copy)
Of course this can change and evolve over time. The main idea is to have a standard place that is globally accessible and short pathed (you could easily type /int/bin/check if /int/bin is not in your path) at a well known path name. Also to sort of replicate or mimic the OS's standard directories like bin, etc, and the like so that it's easily understandable and "natural".
Vinnie pointed out that the packaging script for LOS178 fails to include libstdc++.a. I've looked into this and found that while libstdc++.a is part of 2.1.0, 3.0.0 and GD the packaging script for all 3 failed to include libstdc++.a in the tar images. Further, 3.0.0 includes CR 542, the new TCPIP stack, yet the packaging script does not package up the new TCPIP stack. GD also included the new TCPIP stack ported under CR 15 and I had modified the packaging script on GD to do that.
Here's what I think should happen:
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:
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?
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?
I spent some time improving the web based CVS Reports. As you know I recently added reporting for Bluecat Eng and Bluecat Pkgs. But I've also improved the detailed report (e.g. See the 05/05/2005 report for Bluecat Eng) in the following ways:
I encourage you to visit these reports. They really can be quite useful. Maybe we can finally turn off the daily email.... ?
Vinnie pointed out that the packaging script for LOS178 fails to include libstdc++.a. I've looked into this and found that while libstdc++.a is part of 2.1.0, 3.0.0 and GD the packaging script for all 3 failed to include libstdc++.a in the tar images. Further, 3.0.0 includes CR 542, the new TCPIP stack, yet the packaging script does not package up the new TCPIP stack. GD also included the new TCPIP stack ported under CR 15 and I had modified the packaging script on GD to do that.
Here's what I think should happen:
I was asked to build BC 5.3 so I started doing that yesterday (5/2). Today, thanks to the CVS Reports, comparing 20050502 and 20050503, I noticed a few files were checked in yesterday. Specifically int/etc/bc_build_packages and int/etc/build_trg.rc.pmac_g5. Since my build is already started I'm wondering what effect these checkins have.
There is yet another new checkin for int/etc/additional_bc_packages today.
Also, I attempted the build as root this time from the start hoping that picking up these new checkins would allow the build to succeed. Strangely it failed at step 4.71, building nfs-utils:
rpc_sample.c:32: warning: `sccsid' defined but not used
getiversion.o: file not recognized: File format not recognized
collect2: ld returned 1 exit status
make[2]: *** [getiversion] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2
error: Bad exit status from /usr/lynx/loc_archive/build/20050429/var/tmp/rpm-tmp.28759 (%build)
Bad exit status from /usr/lynx/loc_archive/build/20050429/var/tmp/rpm-tmp.28759 (%build)
I'm not sure how to proceed with the BC build at this point.
I was told to rebuild BC 5.3 as there have been changes that have been checked in. In talking with Sasha I learned that I should login as root and run the do_it script. Sasha said I can specify -h int@t3 to use the int user for CVS checkouts. The do_it script should su to the appropriate users at the appropriate times, etc...
One issue that I found before is one that I found where step 7 had a problem with /mnt/cdrom being already mounted, so I su'ed to root and umounted it. As this build procedure is so long I do not want to get through steps 1-6 only to hit a problem at step 7. I think, however, that step 7 should be enhanced to handle the possibility that /mnt/cdrom is already mounted or the instructions updated to reflect that /mnt/cdrom should not be mounted before starting the build script.
The next problem I had was that do_it su's to bin and attempts to create directories under archive and build for the date but it can't because these parent directories were previously created by int. Changed the owner to bin:bin.
Now I have a problem in that apparently the syntax of -t int@t3 does not work! Although do_it accepts this syntax and it does set CVSROOT to int@t3:/cm/CVS it then executes step 1 which su's to root (!) and eventually does a cvs export -r R_5_3_ppc_20050429 eng/int which fails because root cannot rsh to t3 without a password. Furthermore step 1 is a series of commands, the next of which executes bc_build_host_gnutools.sh which I suspect should be executed as root.
Switch back to starting do_it as the user int is no good because do_it first attempts to su to bin to create directories. int cannot su passwordless to bin. Catch 22!
To address this problem I changed the do_it script:
BUILD_CVS_OWNER=int
...
STEP1_CMD="cd $BC_SRC_PREFIX; su $BUILD_CVS_OWNER -c \"cvs export -r $BC_CVS_TAG eng/int\"; \
$SCRIPTS_PREFIX/bc_build_host_gnutools.sh; \
su $BUILD_CVS_OWNER -c \"$SCRIPTS_PREFIX/bc_cvs.sh\""
This addresses the cvs export command in STEP1_CMD however there's another problem: bc_build_host_gnutools.sh also issues CVS commands and they similarly fail with "permission denied" errors.
I believe the basic problem is this: BC utilizes CVS' :ext: method for accessing the repository. This method in turn utilizes the underlying transport mechanism of rsh (note that ssh can be used instead by setting CVS_RSH=ssh and, of course, you must have ssh installed - which jaguar does not). In order to use rsh as a transport you must have passwordless login via rsh as the user who executed the CVS command - not the user specification in CVSROOT!!! The Cederqvist seems to bear this out under it's troubleshooting section:
| :ext: | Try running the rsh program from the command line. For example: "rsh servername cvs -v" should print cvs version information. If this doesn’t work, you need to fix it before you can worry about cvs problems. |
So even though CVSROOT says :ext:int@t3:/cm/CVS when a CVS command is run as the user root then the user root needs to be able to rsh to the server without specifying a password. This is a good argument for BC to be set up to use :pserver: instead of :ext: access to the CVS repository.
Changing step 1 to be executed entirely by BUILD_CVS_OWNER:
STEP1_CMD="su $BUILD_CVS_OWNER -c \"cd $BC_SRC_PREFIX; \
cvs export -r $BC_CVS_TAG eng/int; \
$SCRIPTS_PREFIX/bc_build_host_gnutools.sh; \
$SCRIPTS_PREFIX/bc_cvs.sh\""
Argh! That's not gonna work because bc_build_host_gnutools.sh wants to write out files to directories owned by bin!
I think I'm gonna go back to my stepwise method for now. Still this stepwise method produces RPMs that have ownership problems (files in RPMs are owned by int:staff instead of bin:bin).