defaria.com/blogs/Status/archives/week_2005_05_15.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 15, 2005 - May 21, 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/week_2005_05_08.html" title="May  8, 2005 - May 14, 2005" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/week_2005_05_22.html" title="May 22, 2005 - May 28, 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/week_2005_05_08.html">&laquo; May  8, 2005 - May 14, 2005</a> |
  36                         <a href="http://defaria.com/blogs/Status/">Main</a>
  37                         | <a href="http://defaria.com/blogs/Status/archives/week_2005_05_22.html">May 22, 2005 - May 28, 2005 &raquo;</a>
  38                      </p>
  39
  40
  41
  42
  43                      <h2 class="date-header">May 20, 2005</h2>
  44                      <a id="a000360"></a>
  45                      <div class="entry" id="entry-360">
  46                         <h3 class="entry-header">LinuxABI/CVS Report - Changes Only</h3>
  47                         <div class="entry-content">
  48                            <div class="entry-body">
  49                               <ul>
  50   <li>Need to have a PowerMac G5 with Yellow Dog Linux 4.0 to build LinuxABI</li>
  51
  52   <li>Improved cvsr.php to support reports that contains only the changes from the last report.</li>
  53 </ul>
  54
  55                               <p class="entry-footer">
  56                                  <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>
  57
  58
  59                               </p>
  60                            </div>
  61                         </div>
  62                      </div>
  63
  64
  65
  66                      <h2 class="date-header">May 19, 2005</h2>
  67                      <a id="a000359"></a>
  68                      <div class="entry" id="entry-359">
  69                         <h3 class="entry-header">LOS178 TOT</h3>
  70                         <div class="entry-content">
  71                            <div class="entry-body">
  72                               <ul>
  73   <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>
  74
  75   <li>Managed to build LOS178 TOT (i.e. + CR #570). Some other CRs were checked in to resolve past build problems</li>
  76
  77   <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>
  78 </ul>
  79
  80                               <h3>OpenSSL</h3>
  81
  82 <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>
  83
  84 <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>
  85
  86 <p>Later Vinnie points out:</p>
  87
  88 <blockquote>
  89 <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>
  90
  91 <p>On linux host the error is:</p>
  92
  93 <blockquote>
  94      ": cannot execute binary file"
  95 </blockquote>
  96
  97 <p>On Solaris host the error is</p>
  98
  99 <blockquote>
 100      ": syntax error at line 1: `(' unexpected"
 101 </blockquote>
 102
 103 <p>File a CR for this problem and maybe suggest the two option below.</p>
 104
 105 <p>There are two options to fix this issue:</p>
 106
 107 <ol>
 108   <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>
 109
 110   <li>Generate the certificates, but the appropriate openssl should be installed in the host system & pass the openssl path to the Makefile command.</li>
 111 </ol>
 112 </blockquote>
 113
 114                               <p class="entry-footer">
 115                                  <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>
 116
 117
 118                               </p>
 119                            </div>
 120                         </div>
 121                      </div>
 122
 123
 124
 125                      <h2 class="date-header">May 18, 2005</h2>
 126                      <a id="a000358"></a>
 127                      <div class="entry" id="entry-358">
 128                         <h3 class="entry-header">LOS178-570/int/package and check</h3>
 129                         <div class="entry-content">
 130                            <div class="entry-body">
 131                               <ul>
 132   <li>Attempting to build LOS178 - CR 570 (Posix)</li>
 133
 134   <li>Tried to make changes for package.sh. Problems are:</li>
 135
 136   <ol>
 137     <li>Waiting for CR fom Moscow to address including of libstdc++ for LOS 2.1.0</li>
 138
 139     <li>GD lacks libstdc++ from ppc.cdksol.tar.gz! Entered CR #38 for that</lii>
 140
 141     <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>
 142   </ol>
 143
 144   <li>Described new scripts for check and package. Check can be used to help tally the number of growing warnings</li>
 145
 146   <li>Described plan for a /int area so as to centralized our tools and scripts</li>
 147 </ul>
 148
 149                               <h3>Check and Package</h3>
 150
 151 <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>
 152
 153 <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>
 154
 155 <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>
 156
 157 <h4>Check script</h4>
 158
 159 <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>
 160 <div class="code"><pre>
 161     Usage: check [-u] [-v] [-d] [-t] [-w] <logfile [logfile]>
 162
 163     Where:
 164
 165             -u              Display usage
 166             -v              Turn on verbose mode
 167             -d              Turn on debug mode
 168             -t              Display total line
 169             -w              Include warnings
 170             <logfile>       One or more log files to check
 171 </pre</div>
 172 <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>
 173
 174 <h4>Package script</h4>
 175
 176 <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>
 177
 178 <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>
 179
 180 <p>Here is a small Perl snippet that utilizes the LWPackage methods:</p>
 181 <div class="code"><pre>
 182     my $pkg = LWPackage->new (spec => $spec);
 183     $pkg->list if get_verbose;
 184     $pkg->package;
 185 </pre></div>
 186 <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>
 187
 188 <h4>Package spec file</h4>
 189
 190 <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>
 191 <div class="code"><pre>
 192     Name:       int
 193     Version:    1.0
 194     ProductNbr: 1000
 195     Release:    00
 196     Base:       /int
 197     Fileset:
 198         *
 199         -data
 200     EndFileset
 201 </pre></div>
 202 <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>
 203 <div class="code"><pre>
 204     Fileset:
 205         adm
 206         bin
 207         spec
 208         -data
 209         -web
 210     EndFileset
 211 </pre></div>
 212 <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>
 213
 214 <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>
 215
 216 <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>
 217
 218 <h3>A plan for /int</h4>
 219
 220 <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>
 221
 222 <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>
 223
 224 <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>
 225
 226 <p>As for what gets put into /int I see the following directory structure:</p>
 227
 228 <blockquote>
 229 <b>adm:</b> Administrative area
 230   <blockquote>
 231   <b>bin:</b> Administrative bin scripts<br>
 232   <b>data:</b> Any adm data files that you might need<br>
 233   <b>etc:</b> Rough equivalent of /etc<br>
 234   <b>functions:</b> bash script functions (currently symlinked to ../functions)
 235   </blockquote>
 236 <b>bin:</b> Scripts and apps for int<br>
 237 <b>data:</b> Any data you might want<br>
 238 <b>functions:</b> bash script functions<br>
 239 <b>lib:</b> For Perl and other library modules<br>
 240 <b>spec:</b> Spec files (may get rid of this)<br>
 241 <b>test:</b> Any test scripts. For example, test script to test the functionality of the modules in ../lib<br>
 242 <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)
 243 </blockquote>
 244
 245 <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>
 246
 247                               <p class="entry-footer">
 248                                  <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>
 249
 250
 251                               </p>
 252                            </div>
 253                         </div>
 254                      </div>
 255
 256
 257
 258                      <h2 class="date-header">May 17, 2005</h2>
 259                      <a id="a000357"></a>
 260                      <div class="entry" id="entry-357">
 261                         <h3 class="entry-header">LOS178 TOT</h3>
 262                         <div class="entry-content">
 263                            <div class="entry-body">
 264                               <ul>
 265   <li>Attempted to build LOS178 TOT. Not successful</li>
 266
 267   <li>Need to check in changes for package.sh for all of LOS 3.0.0, 2.1.0 and GD</li>
 268 </ul>
 269
 270                               <h3>Package.sh changes</h3>
 271
 272 <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>
 273
 274 <p>Here's what I think should happen:</p>
 275
 276 <h4>For LOS178 2.1.0:</h4>
 277
 278 <ul>
 279   <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>
 280
 281   <li>What CR should this be done under?</li>
 282
 283   <li>Since there will probably be a rebuild of 2.1.0 do not repackage at this time.</li>
 284 </ul>
 285
 286 <h4>For GD:</h4>
 287
 288 <ul>
 289   <li>Change the packaging script for GD to include lib/libstdc++.a and lib/thread/libstdc++.a.</li>
 290
 291   <li>Check in those changes under CR 15 (?).</li>
 292
 293   <li>Repackage GD.</li>
 294 </ul>
 295
 296 <h4>For LOS178 3.0.0:</h4>
 297
 298 <ul>
 299   <li>Back port the GD packaging script to 3.0.0.</li>
 300
 301   <li>Check in under CR 542 (?).</li>
 302
 303   <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>
 304 </ul>
 305
 306                               <p class="entry-footer">
 307                                  <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>
 308
 309
 310                               </p>
 311                            </div>
 312                         </div>
 313                      </div>
 314
 315
 316
 317                      <h2 class="date-header">May 16, 2005</h2>
 318                      <a id="a000356"></a>
 319                      <div class="entry" id="entry-356">
 320                         <h3 class="entry-header">GD Build Doc</h3>
 321                         <div class="entry-content">
 322                            <div class="entry-body">
 323                               <ul>
 324   <li>Updated GD Build Document</li>
 325
 326   <li>Starting making a more standardized <i>check</i> script to check for errors as well as warnings and return a count</li>
 327 </ul>
 328
 329                               <p class="entry-footer">
 330                                  <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>
 331
 332
 333                               </p>
 334                            </div>
 335                         </div>
 336                      </div>
 337
 338                   </div>
 339                </div>
 340             </div>
 341          </div>
 342       </div>
 343    </div>
 344 </body>
 345 </html>