defaria.com/blogs/Status/archives/2005_05.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
   4 <head>
   5    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6    <meta name="generator" content="Movable Type 5.2.3" />
   7
   8    <link rel="stylesheet" href="http://defaria.com/blogs/Status/styles-site.css" type="text/css" />
   9    <link rel="alternate" type="application/atom+xml" title="Atom" href="http://defaria.com/blogs/Status/atom.xml" />
  10    <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://defaria.com/blogs/Status/index.xml"$>" />
  11
  12    <title>Status for Andrew DeFaria: May 2005 Archives</title>
  13
  14    <link rel="start" href="http://defaria.com/blogs/Status/" title="Home" />
  15    <link rel="prev" href="http://defaria.com/blogs/Status/archives/2005_04.html" title="April 2005" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/2005_06.html" title="June 2005" />
  17 </head>
  18 <body class="layout-one-column">
  19    <div id="container">
  20       <div id="container-inner" class="pkg">
  21
  22          <div id="banner">
  23             <div id="banner-inner" class="pkg">
  24                <h1 id="banner-header"><a href="http://defaria.com/blogs/Status/" accesskey="1">Status for Andrew DeFaria</a></h1>
  25                <h2 id="banner-description">Searchable status reports and work log</h2>
  26             </div>
  27          </div>
  28
  29          <div id="pagebody">
  30             <div id="pagebody-inner" class="pkg">
  31                <div id="alpha">
  32                   <div id="alpha-inner" class="pkg">
  33
  34                      <p class="content-nav">
  35                         <a href="http://defaria.com/blogs/Status/archives/2005_04.html">&laquo; April 2005</a> |
  36                         <a href="http://defaria.com/blogs/Status/">Main</a>
  37                         | <a href="http://defaria.com/blogs/Status/archives/2005_06.html">June 2005 &raquo;</a>
  38                      </p>
  39
  40
  41
  42
  43                      <h2 class="date-header">May 26, 2005</h2>
  44                      <a id="a000364"></a>
  45                      <div class="entry" id="entry-364">
  46                         <h3 class="entry-header">Build notes LW/GD and tst</h3>
  47                         <div class="entry-content">
  48                            <div class="entry-body">
  49                               <ul>
  50   <li>Caught up on build notes for 20050425, 20050519 and 20050525 for LW LOS178</li>
  51
  52   <li>Resolved CR 41</li>
  53
  54   <li>Tagged tst's for LW LOS178</li>
  55
  56   <li>Assisted Adisak with lists for CRs 536 and 584</li>
  57 </ul>
  58
  59                               <p class="entry-footer">
  60                                  <span class="post-footers">Posted by  at  6:09 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000364.html">Permalink</a>
  61
  62
  63                               </p>
  64                            </div>
  65                         </div>
  66                      </div>
  67
  68
  69
  70                      <h2 class="date-header">May 25, 2005</h2>
  71                      <a id="a000363"></a>
  72                      <div class="entry" id="entry-363">
  73                         <h3 class="entry-header">LW & GD builds</h3>
  74                         <div class="entry-content">
  75                            <div class="entry-body">
  76                               <ul>
  77   <li>Incorporated CR 598 which fixes the production build</li>
  78
  79   <li>Tagged LW LOS178 20050525, rebuilt, released</li>
  80
  81   <li>Ported CR 598 to GD</li>
  82
  83   <li>Tagged GD LOS178 20050525, rebuilt, released</li>
  84
  85   <li>Created build_notes for GD 20050428</li>
  86
  87   <li>Associated updating of related CRs</li>
  88 </ul>
  89
  90                               <p class="entry-footer">
  91                                  <span class="post-footers">Posted by  at  6:38 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000363.html">Permalink</a>
  92
  93
  94                               </p>
  95                            </div>
  96                         </div>
  97                      </div>
  98
  99
 100
 101
 102                      <a id="a000362"></a>
 103                      <div class="entry" id="entry-362">
 104                         <h3 class="entry-header">PPC Pdn build Failure/CVS Report bug</h3>
 105                         <div class="entry-content">
 106                            <div class="entry-body">
 107                               <ul>
 108   <li>Was unable to build ppd_pdn due to a bug</li>
 109
 110   <li>Found a bug in cvs_report regarding new directories</li>
 111 </ul>
 112
 113                               <h3>cvs_report bug</h3>
 114
 115 <p>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.</p>
 116
 117 <p>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.</p>
 118
 119 <p>Additionally cvs_report had an error in a regex such that it was not identifying these new files properly. This has also been fixed.</p>
 120
 121                               <p class="entry-footer">
 122                                  <span class="post-footers">Posted by  at  6:30 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000362.html">Permalink</a>
 123
 124
 125                               </p>
 126                            </div>
 127                         </div>
 128                      </div>
 129
 130
 131
 132                      <h2 class="date-header">May 23, 2005</h2>
 133                      <a id="a000361"></a>
 134                      <div class="entry" id="entry-361">
 135                         <h3 class="entry-header">files4cr</h3>
 136                         <div class="entry-content">
 137                            <div class="entry-body">
 138                               <p>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.</p>
 139
 140 <p>However both files4ecr and files4cr work off of the E/CR number identifying <b>all</b> 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!</p>
 141
 142 <p>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</p>
 143
 144 <p>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</p>
 145
 146                               <p class="entry-footer">
 147                                  <span class="post-footers">Posted by  at  2:10 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000361.html">Permalink</a>
 148
 149
 150                               </p>
 151                            </div>
 152                         </div>
 153                      </div>
 154
 155
 156
 157                      <h2 class="date-header">May 20, 2005</h2>
 158                      <a id="a000360"></a>
 159                      <div class="entry" id="entry-360">
 160                         <h3 class="entry-header">LinuxABI/CVS Report - Changes Only</h3>
 161                         <div class="entry-content">
 162                            <div class="entry-body">
 163                               <ul>
 164   <li>Need to have a PowerMac G5 with Yellow Dog Linux 4.0 to build LinuxABI</li>
 165
 166   <li>Improved cvsr.php to support reports that contains only the changes from the last report.</li>
 167 </ul>
 168
 169                               <p class="entry-footer">
 170                                  <span class="post-footers">Posted by  at  2:38 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000360.html">Permalink</a>
 171
 172
 173                               </p>
 174                            </div>
 175                         </div>
 176                      </div>
 177
 178
 179
 180                      <h2 class="date-header">May 19, 2005</h2>
 181                      <a id="a000359"></a>
 182                      <div class="entry" id="entry-359">
 183                         <h3 class="entry-header">LOS178 TOT</h3>
 184                         <div class="entry-content">
 185                            <div class="entry-body">
 186                               <ul>
 187   <li>Tried building LOS178 - CR #570 again. This time by date. Turns out dates in CVS are UTC and you gotta subtract 7 hours from them - Argh!</li>
 188
 189   <li>Managed to build LOS178 TOT (i.e. + CR #570). Some other CRs were checked in to resolve past build problems</li>
 190
 191   <li>Started to package up stuff (still need to create CR for this) with new packaging script. Found out I needed to build pdn. Pdn build fails!</li>
 192 </ul>
 193
 194                               <h3>OpenSSL</h3>
 195
 196 <p>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.</p>
 197
 198 <p>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.</p>
 199
 200 <p>Later Vinnie points out:</p>
 201
 202 <blockquote>
 203 <p>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.</p>
 204
 205 <p>On linux host the error is:</p>
 206
 207 <blockquote>
 208      ": cannot execute binary file"
 209 </blockquote>
 210
 211 <p>On Solaris host the error is</p>
 212
 213 <blockquote>
 214      ": syntax error at line 1: `(' unexpected"
 215 </blockquote>
 216
 217 <p>File a CR for this problem and maybe suggest the two option below.</p>
 218
 219 <p>There are two options to fix this issue:</p>
 220
 221 <ol>
 222   <li>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</li>
 223
 224   <li>Generate the certificates, but the appropriate openssl should be installed in the host system & pass the openssl path to the Makefile command.</li>
 225 </ol>
 226 </blockquote>
 227
 228                               <p class="entry-footer">
 229                                  <span class="post-footers">Posted by  at  2:35 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000359.html">Permalink</a>
 230
 231
 232                               </p>
 233                            </div>
 234                         </div>
 235                      </div>
 236
 237
 238
 239                      <h2 class="date-header">May 18, 2005</h2>
 240                      <a id="a000358"></a>
 241                      <div class="entry" id="entry-358">
 242                         <h3 class="entry-header">LOS178-570/int/package and check</h3>
 243                         <div class="entry-content">
 244                            <div class="entry-body">
 245                               <ul>
 246   <li>Attempting to build LOS178 - CR 570 (Posix)</li>
 247
 248   <li>Tried to make changes for package.sh. Problems are:</li>
 249
 250   <ol>
 251     <li>Waiting for CR fom Moscow to address including of libstdc++ for LOS 2.1.0</li>
 252
 253     <li>GD lacks libstdc++ from ppc.cdksol.tar.gz! Entered CR #38 for that</lii>
 254
 255     <li>It was thought that changes to package.sh could be made without the need for a CR. Unfortunately the CVS setup is such that a CR is required, even for comitting changes to toolbox</li>
 256   </ol>
 257
 258   <li>Described new scripts for check and package. Check can be used to help tally the number of growing warnings</li>
 259
 260   <li>Described plan for a /int area so as to centralized our tools and scripts</li>
 261 </ul>
 262
 263                               <h3>Check and Package</h3>
 264
 265 <p>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.</p>
 266
 267 <p>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.</p>
 268
 269 <p>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.</p>
 270
 271 <h4>Check script</h4>
 272
 273 <p>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:</p>
 274 <div class="code"><pre>
 275     Usage: check [-u] [-v] [-d] [-t] [-w] <logfile [logfile]>
 276
 277     Where:
 278
 279             -u              Display usage
 280             -v              Turn on verbose mode
 281             -d              Turn on debug mode
 282             -t              Display total line
 283             -w              Include warnings
 284             <logfile>       One or more log files to check
 285 </pre</div>
 286 <p>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.</p>
 287
 288 <h4>Package script</h4>
 289
 290 <p>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.</p>
 291
 292 <p>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.</p>
 293
 294 <p>Here is a small Perl snippet that utilizes the LWPackage methods:</p>
 295 <div class="code"><pre>
 296     my $pkg = LWPackage->new (spec => $spec);
 297     $pkg->list if get_verbose;
 298     $pkg->package;
 299 </pre></div>
 300 <p>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.</p>
 301
 302 <h4>Package spec file</h4>
 303
 304 <p>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:</p>
 305 <div class="code"><pre>
 306     Name:       int
 307     Version:    1.0
 308     ProductNbr: 1000
 309     Release:    00
 310     Base:       /int
 311     Fileset:
 312         *
 313         -data
 314     EndFileset
 315 </pre></div>
 316 <p>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:</p>
 317 <div class="code"><pre>
 318     Fileset:
 319         adm
 320         bin
 321         spec
 322         -data
 323         -web
 324     EndFileset
 325 </pre></div>
 326 <p>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".</p>
 327
 328 <p>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).</p>
 329
 330 <p>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.</p>
 331
 332 <h3>A plan for /int</h4>
 333
 334 <p>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.</p>
 335
 336 <p>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.</p>
 337
 338 <p>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 &gt;RELTAG&lt; /export/int to make sure that /export/int reflects <RELTAG> where &gt;RELTAG&lt; 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 &gt;RELTAG&lt; to the committed version. The updated version would be available the next day (or we could force it by hand if necessary).</p>
 339
 340 <p>As for what gets put into /int I see the following directory structure:</p>
 341
 342 <blockquote>
 343 <b>adm:</b> Administrative area
 344   <blockquote>
 345   <b>bin:</b> Administrative bin scripts<br>
 346   <b>data:</b> Any adm data files that you might need<br>
 347   <b>etc:</b> Rough equivalent of /etc<br>
 348   <b>functions:</b> bash script functions (currently symlinked to ../functions)
 349   </blockquote>
 350 <b>bin:</b> Scripts and apps for int<br>
 351 <b>data:</b> Any data you might want<br>
 352 <b>functions:</b> bash script functions<br>
 353 <b>lib:</b> For Perl and other library modules<br>
 354 <b>spec:</b> Spec files (may get rid of this)<br>
 355 <b>test:</b> Any test scripts. For example, test script to test the functionality of the modules in ../lib<br>
 356 <b>web:</b> 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)
 357 </blockquote>
 358
 359 <p>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".</p>
 360
 361                               <p class="entry-footer">
 362                                  <span class="post-footers">Posted by  at  6:27 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000358.html">Permalink</a>
 363
 364
 365                               </p>
 366                            </div>
 367                         </div>
 368                      </div>
 369
 370
 371
 372                      <h2 class="date-header">May 17, 2005</h2>
 373                      <a id="a000357"></a>
 374                      <div class="entry" id="entry-357">
 375                         <h3 class="entry-header">LOS178 TOT</h3>
 376                         <div class="entry-content">
 377                            <div class="entry-body">
 378                               <ul>
 379   <li>Attempted to build LOS178 TOT. Not successful</li>
 380
 381   <li>Need to check in changes for package.sh for all of LOS 3.0.0, 2.1.0 and GD</li>
 382 </ul>
 383
 384                               <h3>Package.sh changes</h3>
 385
 386 <p>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.</p>
 387
 388 <p>Here's what I think should happen:</p>
 389
 390 <h4>For LOS178 2.1.0:</h4>
 391
 392 <ul>
 393   <li>Change the packaging script to include lib/libstdc++.a and lib/thread/libstdc++.a. This script will live on the REL_LOS178_2p1p0-branch.</li>
 394
 395   <li>What CR should this be done under?</li>
 396
 397   <li>Since there will probably be a rebuild of 2.1.0 do not repackage at this time.</li>
 398 </ul>
 399
 400 <h4>For GD:</h4>
 401
 402 <ul>
 403   <li>Change the packaging script for GD to include lib/libstdc++.a and lib/thread/libstdc++.a.</li>
 404
 405   <li>Check in those changes under CR 15 (?).</li>
 406
 407   <li>Repackage GD.</li>
 408 </ul>
 409
 410 <h4>For LOS178 3.0.0:</h4>
 411
 412 <ul>
 413   <li>Back port the GD packaging script to 3.0.0.</li>
 414
 415   <li>Check in under CR 542 (?).</li>
 416
 417   <li>Repackage 3.0.0. This will fix both the problem of not packaging the new TCPIP stack as well as including the libstdc++ components.</li>
 418 </ul>
 419
 420                               <p class="entry-footer">
 421                                  <span class="post-footers">Posted by  at  6:19 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000357.html">Permalink</a>
 422
 423
 424                               </p>
 425                            </div>
 426                         </div>
 427                      </div>
 428
 429
 430
 431                      <h2 class="date-header">May 16, 2005</h2>
 432                      <a id="a000356"></a>
 433                      <div class="entry" id="entry-356">
 434                         <h3 class="entry-header">GD Build Doc</h3>
 435                         <div class="entry-content">
 436                            <div class="entry-body">
 437                               <ul>
 438   <li>Updated GD Build Document</li>
 439
 440   <li>Starting making a more standardized <i>check</i> script to check for errors as well as warnings and return a count</li>
 441 </ul>
 442
 443                               <p class="entry-footer">
 444                                  <span class="post-footers">Posted by  at  4:00 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000356.html">Permalink</a>
 445
 446
 447                               </p>
 448                            </div>
 449                         </div>
 450                      </div>
 451
 452
 453
 454                      <h2 class="date-header">May 13, 2005</h2>
 455                      <a id="a000355"></a>
 456                      <div class="entry" id="entry-355">
 457                         <h3 class="entry-header">LOS178 TOT Build</h3>
 458                         <div class="entry-content">
 459                            <div class="entry-body">
 460                               <ul>
 461   <li>Attempted to build LOS178 TOT which is failing</li>
 462
 463   <li>Attempted to build LOS 178 TOT for Linux cross. Also failing</li>
 464
 465   <li>Updated <i>FCS ICS Hybrid OS Build Procedure</i> document</li>
 466 </ul>
 467
 468                               <p class="entry-footer">
 469                                  <span class="post-footers">Posted by  at  5:45 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000355.html">Permalink</a>
 470
 471
 472                               </p>
 473                            </div>
 474                         </div>
 475                      </div>
 476
 477
 478
 479                      <h2 class="date-header">May 11, 2005</h2>
 480                      <a id="a000354"></a>
 481                      <div class="entry" id="entry-354">
 482                         <h3 class="entry-header">CVS Reports</h3>
 483                         <div class="entry-content">
 484                            <div class="entry-body">
 485                               <ul>
 486   <li>Implemented many improvements to cvs_report.pl</li>
 487
 488   <li>Implemented some improvements to cvsr.php</li>
 489
 490   <li>Re-performed steps 1, 8-12 of BC build in order to pickup changes to tests and demos. Made new images available at <a href="ftp://saturn">ftp://saturn</a>.
 491 </ul>
 492
 493                               <h3>CVS Report Improvements</h3>
 494
 495 <p>Main problem addressed is that certain ECRs (or CRs) would show up if they were imported from a <i>vendor</i> branch. In general handling of revisions on branchs were not working very well. Other improvements include:</p>
 496
 497 <ul>
 498   <li>Changed to use Display package</li>
 499
 500   <li>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.</li>
 501
 502   <li>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 <i>vendor</i> branch and is an alias for 1.1. This special situation is now better handled.</li>
 503
 504   <li>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</li>
 505
 506   <li>Detection of no change is now better handled</li>
 507 </ul>
 508
 509 <h3>cvsr.php Improvements</h3>
 510
 511 <ul>
 512   <li>Now properly reports the latest revision when multiple revisions are checked in for the same ECR</li>
 513
 514    <li>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.</li>
 515 </ul>
 516
 517                               <p class="entry-footer">
 518                                  <span class="post-footers">Posted by  at 12:36 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000354.html">Permalink</a>
 519
 520
 521                               </p>
 522                            </div>
 523                         </div>
 524                      </div>
 525
 526
 527
 528                      <h2 class="date-header">May 10, 2005</h2>
 529                      <a id="a000353"></a>
 530                      <div class="entry" id="entry-353">
 531                         <h3 class="entry-header">BC 5.3 on RH 8.0</h3>
 532                         <div class="entry-content">
 533                            <div class="entry-body">
 534                               <p>Wrote the following to Sasha today:</p>
 535
 536 <p>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.</p>
 537
 538 <p>I've tried twice now and it continues to fail in step 4.1 building the kernel. The following appears in build_kernel.log:</p>
 539 <div class="code"><pre>
 540 + echo BUILDING A KERNEL FOR pmac_g5...
 541 + cp /build/bluecat/build/20050429/cdt/src/bluecat/SOURCES/bluecat-pmac_g5.config arch/ppc/defconfig
 542 + rm -f .config
 543 + make mrproper
 544 + make oldconfig
 545 /bin/sh: line 1: bc_native_gcc: command not found
 546 make[1]: *** [scripts/basic/fixdep] Error 127
 547 make: *** [scripts_basic] Error 2
 548 error: Bad exit status from /build/bluecat/build/20050429/var/tmp/rpm-tmp.94728 (%build)
 549     Bad exit status from /build/bluecat/build/20050429/var/tmp/rpm-tmp.94728 (%build)
 550 </pre></div>
 551 <p>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.</p>
 552
 553 <p>Ideas?</p>
 554
 555                               <p class="entry-footer">
 556                                  <span class="post-footers">Posted by  at  9:22 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000353.html">Permalink</a>
 557
 558
 559                               </p>
 560                            </div>
 561                         </div>
 562                      </div>
 563
 564
 565
 566                      <h2 class="date-header">May  9, 2005</h2>
 567                      <a id="a000352"></a>
 568                      <div class="entry" id="entry-352">
 569                         <h3 class="entry-header">CVS Report bug</h3>
 570                         <div class="entry-content">
 571                            <div class="entry-body">
 572                               <p>The more I look into CVS the less I understand. Perhaps you can help me...</p>
 573
 574 <p>For the file los178/sys/kernel/getmem.c I see the following:</p>
 575 <div class="code"><pre>
 576 saturn:cvs log getmem.c
 577
 578 RCS file: /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
 579 Working file: getmem.c
 580 head: 1.2
 581 branch:
 582 locks: strict
 583 access list:
 584 symbolic names:
 585        DEV_LOS178_2p1p0_ppc_20050503: 1.1.1.1.2.1
 586        REL_LOS178_2p0p0-branch: 1.1.1.1.0.4
 587                  ...
 588        REL_LOS178RSC_2p0p0_ppc_FCS: 1.1.1.1
 589                  ...
 590 saturn:cvs st getmem.c
 591 ===================================================================
 592 File: getmem.c          Status: Up-to-date
 593
 594   Working revision:    1.1.1.1
 595   Repository revision: 1.1.1.1 /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
 596   Sticky Tag:          REL_LOS178_2p0p0_ppc_FCS (revision: 1.1.1.1)
 597   Sticky Date:         (none)
 598   Sticky Options:      -ko
 599 </pre></div>
 600 <p>In particular here notice that head says 1.2 but the current working revision is 1.1.1.1. The CVS Report does a:</p>
 601 <div class="code"><pre>
 602 saturn:cvs diff --brief -r HEAD getmem.c
 603 saturn:
 604 </pre></div>
 605 <p>Does this mean that there is no difference between 1.1.1.1 and 1.2?!? However if I do:</p>
 606 <div class="code"><pre>
 607 saturn:cvs diff --brief -r 1.2 getmem.c
 608 Index: getmem.c
 609 ===================================================================
 610 RCS file: /cvs/los178-cvs/los178/sys/kernel/getmem.c,v
 611 retrieving revision 1.2
 612 retrieving revision 1.1.1.1
 613 diff --brief -r1.2 -r1.1.1.1
 614 Files /tmp/cvsvGa4M1 and /tmp/cvswGa4M1 differ
 615 saturn:
 616 </pre></div>
 617 <p>Why is this so? Doesn't -r HEAD mean 1.2 in this instance?</p>
 618
 619                               <p class="entry-footer">
 620                                  <span class="post-footers">Posted by  at  2:59 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000352.html">Permalink</a>
 621
 622
 623                               </p>
 624                            </div>
 625                         </div>
 626                      </div>
 627
 628
 629
 630                      <h2 class="date-header">May  5, 2005</h2>
 631                      <a id="a000351"></a>
 632                      <div class="entry" id="entry-351">
 633                         <h3 class="entry-header">New CVS Reports</h3>
 634                         <div class="entry-content">
 635                            <div class="entry-body">
 636                               <p>I spent some time improving the web based CVS Reports. As you know I recently added reporting for <a href="http://saturn.lynx.com/cvsr/bluecat_eng">Bluecat Eng</a> and <a href="http://saturn.lynx.com/cvsr/bluecat_pkgs">Bluecat Pkgs</a>. But I've also improved the detailed report (e.g. See the <a href="http://saturn.lynx.com/cvsr/bluecat_eng/index.php?file=20050505">05/05/2005</a> report for Bluecat Eng) in the following ways:</p>
 637
 638 <ul>
 639   <li>Report now accurately counts files in ECRs as well as the Total file count. Previously if foo.c was checked in as 1.2 then later foo.c was checked in as 1.3 both would be listed thus inflating the file count. This has been fixed.</li>
 640
 641   <li>Changes of files since the previous report are now <font color="red"><b>highlighted</b></font>. This is a very useful thing because the first question you ask yourself when looking at a report is "What changed?". While this might seem trivial it required a lot of rewriting of the PHP code to accomplish this. Since this is just the PHP code that displays the report it has become immediately effective on all previous reports too!</li>
 642 </ul>
 643
 644 <p>I encourage you to visit these reports. They really can be quite useful. Maybe we can finally turn off the daily email.... ?</p>
 645
 646                               <p class="entry-footer">
 647                                  <span class="post-footers">Posted by  at 11:42 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000351.html">Permalink</a>
 648
 649
 650                               </p>
 651                            </div>
 652                         </div>
 653                      </div>
 654
 655
 656
 657
 658                      <a id="a000350"></a>
 659                      <div class="entry" id="entry-350">
 660                         <h3 class="entry-header">Changes to the LOS178/GD packaging scripts</h3>
 661                         <div class="entry-content">
 662                            <div class="entry-body">
 663                               <p>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.</p>
 664
 665 <p>Here's what I think should happen:</p>
 666
 667 <h3>For LOS178 2.1.0:</h3>
 668
 669 <ul>
 670   <li>Change the packaging script to include lib/libstdc++.a and lib/thread/libstdc++.a. This script will live on the REL_LOS178_2p1p0-branch.</li>
 671
 672   <li>What CR should this be done under?</li>
 673
 674   <li>Since there will probably be a rebuild of 2.1.0 do not repackage at this time.</li>
 675 </ul>
 676
 677 <h3>For GD:</h3>
 678
 679 <ul>
 680   <li>Change the packaging script for GD to include lib/libstdc++.a and lib/thread/libstdc++.a.</li>
 681
 682   <li>Check in those changes under CR 15 (?).</li>
 683
 684   <li>Repackage GD.</li>
 685 </ul>
 686
 687 <h3>For LOS178 3.0.0</h3>
 688
 689 <ul>
 690   <li>Back port the GD packaging script to 3.0.0.</li>
 691
 692   <li>Check in under CR 542 (?).</li>
 693
 694   <li>Repackage 3.0.0. This will fix both the problem of not packaging the new TCPIP stack as well as including the libstdc++ components.</li>
 695 </ul>
 696
 697                               <p class="entry-footer">
 698                                  <span class="post-footers">Posted by  at 11:19 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000350.html">Permalink</a>
 699
 700
 701                               </p>
 702                            </div>
 703                         </div>
 704                      </div>
 705
 706
 707
 708                      <h2 class="date-header">May  4, 2005</h2>
 709                      <a id="a000349"></a>
 710                      <div class="entry" id="entry-349">
 711                         <h3 class="entry-header">BC Build failure</h3>
 712                         <div class="entry-content">
 713                            <div class="entry-body">
 714                               <ul>
 715   <li>Attempted full su build of BC from scratch</li>
 716
 717   <li>Changed CVS Reports to highlight the differences between this report and the previous one</li>
 718 </ul>
 719
 720                               Andrew DeFaria wrote:
 721
 722 <blockquote type=cite>
 723 <p>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.</p>
 724 </blockquote>
 725
 726 <p>There is yet another new checkin for int/etc/additional_bc_packages today.</p>
 727
 728 <p>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:</p>
 729
 730 <div class="code"><pre>
 731 rpc_sample.c:32: warning: `sccsid' defined but not used
 732 getiversion.o: file not recognized: File format not recognized
 733 collect2: ld returned 1 exit status
 734 make[2]: *** [getiversion] Error 1
 735 make[1]: *** [all] Error 2
 736 make: *** [all] Error 2
 737 error: Bad exit status from /usr/lynx/loc_archive/build/20050429/var/tmp/rpm-tmp.28759 (%build)
 738     Bad exit status from /usr/lynx/loc_archive/build/20050429/var/tmp/rpm-tmp.28759 (%build)
 739 </pre></div>
 740
 741 <p>I'm not sure how to proceed with the BC build at this point.</p>
 742
 743                               <p class="entry-footer">
 744                                  <span class="post-footers">Posted by  at 10:04 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000349.html">Permalink</a>
 745
 746
 747                               </p>
 748                            </div>
 749                         </div>
 750                      </div>
 751
 752
 753
 754                      <h2 class="date-header">May  3, 2005</h2>
 755                      <a id="a000348"></a>
 756                      <div class="entry" id="entry-348">
 757                         <h3 class="entry-header">BC Build & LOS178 2.1.0 TOB</h3>
 758                         <div class="entry-content">
 759                            <div class="entry-body">
 760                               <ul>
 761   <li>Attempted build of Bluecat 5.3. Build failed in 4.102. New checkins happened so I will attempt a rebuild</li>
 762
 763   <li>Built and released LOS178 2.1.0 TOB</li>
 764 </ul>
 765
 766                               <p class="entry-footer">
 767                                  <span class="post-footers">Posted by  at  3:07 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000348.html">Permalink</a>
 768
 769
 770                               </p>
 771                            </div>
 772                         </div>
 773                      </div>
 774
 775
 776
 777                      <h2 class="date-header">May  2, 2005</h2>
 778                      <a id="a000347"></a>
 779                      <div class="entry" id="entry-347">
 780                         <h3 class="entry-header">BC 5.3 20050429 drup</h3>
 781                         <div class="entry-content">
 782                            <div class="entry-body">
 783                               <ul>
 784   <li>Worked on building the 20050429 drop of BC 5.3</li>
 785 </ul>
 786
 787                               <p>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...</p>
 788
 789 <p>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.</p>
 790
 791 <p>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.</p>
 792
 793 <p>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.</p>
 794
 795 <p>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!</p>
 796
 797 <p>To address this problem I changed the do_it script:</p>
 798
 799 <div class="code"><pre>
 800 BUILD_CVS_OWNER=int
 801  ...
 802 STEP1_CMD="cd $BC_SRC_PREFIX; su $BUILD_CVS_OWNER -c \"cvs export -r $BC_CVS_TAG eng/int\"; \
 803            $SCRIPTS_PREFIX/bc_build_host_gnutools.sh; \
 804            su $BUILD_CVS_OWNER -c \"$SCRIPTS_PREFIX/bc_cvs.sh\""
 805 </pre></div>
 806
 807 <p>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.</p>
 808
 809 <p>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:</p>
 810
 811 <table border="0" cellpadding="2" cellspacing="0" width="100%">
 812     <tbody>
 813       <tr>
 814         <td valign="middle" width="100">:ext:</td>
 815         <td valign="top">Try running the rsh program from the command
 816 line. For example: "rsh servername cvs -v" should print cvs version
 817 information. If this doesn&#8217;t work, you need to fix it before you can
 818 worry about cvs problems.</td>
 819       </tr>
 820     </tbody>
 821   </table>
 822
 823 <p>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.</p>
 824
 825 <p>Changing step 1 to be executed entirely by BUILD_CVS_OWNER:</p>
 826
 827 <div class="code"><pre>
 828   STEP1_CMD="su $BUILD_CVS_OWNER -c \"cd $BC_SRC_PREFIX; \
 829              cvs export -r $BC_CVS_TAG eng/int; \
 830              $SCRIPTS_PREFIX/bc_build_host_gnutools.sh; \
 831              $SCRIPTS_PREFIX/bc_cvs.sh\""
 832 </pre></div>
 833
 834 <p>Argh! That's not gonna work because bc_build_host_gnutools.sh wants to write out files to directories owned by bin!</p>
 835
 836 <p>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).</p>
 837
 838                               <p class="entry-footer">
 839                                  <span class="post-footers">Posted by  at  2:57 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000347.html">Permalink</a>
 840
 841
 842                               </p>
 843                            </div>
 844                         </div>
 845                      </div>
 846
 847                   </div>
 848                </div>
 849             </div>
 850          </div>
 851       </div>
 852    </div>
 853 </body>
 854 </html>