defaria.com/blogs/Status/archives/week_2005_05_01.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  1, 2005 - May  7, 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_04_24.html" title="April 24, 2005 - April 30, 2005" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/week_2005_05_08.html" title="May  8, 2005 - May 14, 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_04_24.html">&laquo; April 24, 2005 - April 30, 2005</a> |
  36                         <a href="http://defaria.com/blogs/Status/">Main</a>
  37                         | <a href="http://defaria.com/blogs/Status/archives/week_2005_05_08.html">May  8, 2005 - May 14, 2005 &raquo;</a>
  38                      </p>
  39
  40
  41
  42
  43                      <h2 class="date-header">May  5, 2005</h2>
  44                      <a id="a000351"></a>
  45                      <div class="entry" id="entry-351">
  46                         <h3 class="entry-header">New CVS Reports</h3>
  47                         <div class="entry-content">
  48                            <div class="entry-body">
  49                               <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>
  50
  51 <ul>
  52   <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>
  53
  54   <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>
  55 </ul>
  56
  57 <p>I encourage you to visit these reports. They really can be quite useful. Maybe we can finally turn off the daily email.... ?</p>
  58
  59                               <p class="entry-footer">
  60                                  <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>
  61
  62
  63                               </p>
  64                            </div>
  65                         </div>
  66                      </div>
  67
  68
  69
  70
  71                      <a id="a000350"></a>
  72                      <div class="entry" id="entry-350">
  73                         <h3 class="entry-header">Changes to the LOS178/GD packaging scripts</h3>
  74                         <div class="entry-content">
  75                            <div class="entry-body">
  76                               <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>
  77
  78 <p>Here's what I think should happen:</p>
  79
  80 <h3>For LOS178 2.1.0:</h3>
  81
  82 <ul>
  83   <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>
  84
  85   <li>What CR should this be done under?</li>
  86
  87   <li>Since there will probably be a rebuild of 2.1.0 do not repackage at this time.</li>
  88 </ul>
  89
  90 <h3>For GD:</h3>
  91
  92 <ul>
  93   <li>Change the packaging script for GD to include lib/libstdc++.a and lib/thread/libstdc++.a.</li>
  94
  95   <li>Check in those changes under CR 15 (?).</li>
  96
  97   <li>Repackage GD.</li>
  98 </ul>
  99
 100 <h3>For LOS178 3.0.0</h3>
 101
 102 <ul>
 103   <li>Back port the GD packaging script to 3.0.0.</li>
 104
 105   <li>Check in under CR 542 (?).</li>
 106
 107   <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>
 108 </ul>
 109
 110                               <p class="entry-footer">
 111                                  <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>
 112
 113
 114                               </p>
 115                            </div>
 116                         </div>
 117                      </div>
 118
 119
 120
 121                      <h2 class="date-header">May  4, 2005</h2>
 122                      <a id="a000349"></a>
 123                      <div class="entry" id="entry-349">
 124                         <h3 class="entry-header">BC Build failure</h3>
 125                         <div class="entry-content">
 126                            <div class="entry-body">
 127                               <ul>
 128   <li>Attempted full su build of BC from scratch</li>
 129
 130   <li>Changed CVS Reports to highlight the differences between this report and the previous one</li>
 131 </ul>
 132
 133                               Andrew DeFaria wrote:
 134
 135 <blockquote type=cite>
 136 <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>
 137 </blockquote>
 138
 139 <p>There is yet another new checkin for int/etc/additional_bc_packages today.</p>
 140
 141 <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>
 142
 143 <div class="code"><pre>
 144 rpc_sample.c:32: warning: `sccsid' defined but not used
 145 getiversion.o: file not recognized: File format not recognized
 146 collect2: ld returned 1 exit status
 147 make[2]: *** [getiversion] Error 1
 148 make[1]: *** [all] Error 2
 149 make: *** [all] Error 2
 150 error: Bad exit status from /usr/lynx/loc_archive/build/20050429/var/tmp/rpm-tmp.28759 (%build)
 151     Bad exit status from /usr/lynx/loc_archive/build/20050429/var/tmp/rpm-tmp.28759 (%build)
 152 </pre></div>
 153
 154 <p>I'm not sure how to proceed with the BC build at this point.</p>
 155
 156                               <p class="entry-footer">
 157                                  <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>
 158
 159
 160                               </p>
 161                            </div>
 162                         </div>
 163                      </div>
 164
 165
 166
 167                      <h2 class="date-header">May  3, 2005</h2>
 168                      <a id="a000348"></a>
 169                      <div class="entry" id="entry-348">
 170                         <h3 class="entry-header">BC Build & LOS178 2.1.0 TOB</h3>
 171                         <div class="entry-content">
 172                            <div class="entry-body">
 173                               <ul>
 174   <li>Attempted build of Bluecat 5.3. Build failed in 4.102. New checkins happened so I will attempt a rebuild</li>
 175
 176   <li>Built and released LOS178 2.1.0 TOB</li>
 177 </ul>
 178
 179                               <p class="entry-footer">
 180                                  <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>
 181
 182
 183                               </p>
 184                            </div>
 185                         </div>
 186                      </div>
 187
 188
 189
 190                      <h2 class="date-header">May  2, 2005</h2>
 191                      <a id="a000347"></a>
 192                      <div class="entry" id="entry-347">
 193                         <h3 class="entry-header">BC 5.3 20050429 drup</h3>
 194                         <div class="entry-content">
 195                            <div class="entry-body">
 196                               <ul>
 197   <li>Worked on building the 20050429 drop of BC 5.3</li>
 198 </ul>
 199
 200                               <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>
 201
 202 <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>
 203
 204 <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>
 205
 206 <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>
 207
 208 <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>
 209
 210 <p>To address this problem I changed the do_it script:</p>
 211
 212 <div class="code"><pre>
 213 BUILD_CVS_OWNER=int
 214  ...
 215 STEP1_CMD="cd $BC_SRC_PREFIX; su $BUILD_CVS_OWNER -c \"cvs export -r $BC_CVS_TAG eng/int\"; \
 216            $SCRIPTS_PREFIX/bc_build_host_gnutools.sh; \
 217            su $BUILD_CVS_OWNER -c \"$SCRIPTS_PREFIX/bc_cvs.sh\""
 218 </pre></div>
 219
 220 <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>
 221
 222 <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>
 223
 224 <table border="0" cellpadding="2" cellspacing="0" width="100%">
 225     <tbody>
 226       <tr>
 227         <td valign="middle" width="100">:ext:</td>
 228         <td valign="top">Try running the rsh program from the command
 229 line. For example: "rsh servername cvs -v" should print cvs version
 230 information. If this doesn&#8217;t work, you need to fix it before you can
 231 worry about cvs problems.</td>
 232       </tr>
 233     </tbody>
 234   </table>
 235
 236 <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>
 237
 238 <p>Changing step 1 to be executed entirely by BUILD_CVS_OWNER:</p>
 239
 240 <div class="code"><pre>
 241   STEP1_CMD="su $BUILD_CVS_OWNER -c \"cd $BC_SRC_PREFIX; \
 242              cvs export -r $BC_CVS_TAG eng/int; \
 243              $SCRIPTS_PREFIX/bc_build_host_gnutools.sh; \
 244              $SCRIPTS_PREFIX/bc_cvs.sh\""
 245 </pre></div>
 246
 247 <p>Argh! That's not gonna work because bc_build_host_gnutools.sh wants to write out files to directories owned by bin!</p>
 248
 249 <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>
 250
 251                               <p class="entry-footer">
 252                                  <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>
 253
 254
 255                               </p>
 256                            </div>
 257                         </div>
 258                      </div>
 259
 260                   </div>
 261                </div>
 262             </div>
 263          </div>
 264       </div>
 265    </div>
 266 </body>
 267 </html>