[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:USG buildhelp questions/answers
Moderator:SMURF::FILTER
Created:Mon Apr 26 1993
Last Modified:Mon Jan 20 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2763
Total number of notes:5802

2555.0. "nfs_vnodeops.c v32de1supportos submit mystery unfolds" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Sep 10 1996 19:01

Date Of Receipt: 	10-SEP-1996 17:37:00.15
From: 	FLUME::jmf "Joshua M. Friedman Digital UNIX  10-Sep-1996 1733"
To: 	gsn@DEC:.zko.flume
CC: 	tea@DEC:.zko.flume, odehelp@DEC:.zko.flume, kucherov@DEC:.zko.flume
Subj: 	nfs_vnodeops.c v32de1supportos submit mystery unfolds

Gary, looks like you're the first in my experience to have this
happen.  I suppose that's an honor!

Sorry, I couldn't explain this in just a few words.

I've solved the mystery of your 3 submits of kernel/nfs/nfs_vnodeops.c
into v32de1supportos that never materialized, except in the logs.  It
turns out that you have inadvertently submitted into the ptliteos pool
(which of course is locked, but you didn't submit by normal means).

Here's an excerpt from the "sbinfo" you mailed me; these two settings
should agree; both should reflect the v32de1 support pool; this is part
of the symptom, following is the cause:

    % sbinfo
	...
	default_build: ptliteos
	default_set: V32DE1SUPPORTOS
	...

In your sandbox's rc_files directory, you should have the files local,
local.tmpl, shared, shared.tmpl, and sets, which you do (dated 7/10).
However you also have symlinks which look like they were created with
mklinks (on 9/4), to the remaining rc_files in the submit pool, which
control the behavior of your sandbox (see directory listing below).

I'll avoid the detailed explanation, but, normally the rc_files are
read starting with 'local', unless you have a 'custom'.  Because you
do have a custom (linked from the pool), the rc_files begin to be read
there, and from that point on they have settings which they shouldn't.

The settings that you inadvertently picked up included an old incorrect
setting of default_build=ptliteos in the custom.build file, which is
normally reset to the correct pool, but in this case, because of the
funny nonstandard rc_files include structure was not reset.

As a result, the bsubmit.log and SNAPSHOT files were updated in
v32de1supportos, the RCS pool correctly has updated the V32DE1SUPPORTOS
branch, but the final source was copied into the ptliteos pool.

I have removed the extra default_build setting in the pool (and have
restored the original file to ptliteos), and so a new 'sbinfo' from
your sandbox should show the correct default_build, however, ...

You should clean up your rc_files directory, removing all the symlinks
in it, and then it should return to working properly (after you exit
and re-start a new workon session).

-josh


-------------------
    /* sandbox listing */

% hostname
useg98
% pwd
/u/sb/v32de1/rc_files
% ls -l
total 7
lrwxr-xr-x   1 gsn      system        35 Sep  4 17:51 custom -> /u/sb/v32de1/link/./rc_files/custom
lrwxr-xr-x   1 gsn      system        41 Sep  4 17:51 custom.build -> /u/sb/v32de1/link/./rc_files/custom.build
-rw-r--r--   1 gsn      system       588 Jul 10 11:48 local
lrwxr-xr-x   1 gsn      system        48 Sep  4 17:51 local.sharedsandbox -> /u/sb/v32de1/link/./rc_files/local.sharedsandbox
lrwxr-xr-x   1 gsn      system        41 Sep  4 17:51 local.submit -> /u/sb/v32de1/link/./rc_files/local.submit
-rw-r--r--   1 gsn      system       588 Jul 10 11:48 local.tmpl
-rw-r--r--   1 gsn      system        58 Jul 10 11:49 sets
-rw-r--r--   1 gsn      system      1493 Jul 10 11:48 shared
lrwxr-xr-x   1 gsn      system        49 Sep  4 17:51 shared.sharedsandbox -> /u/sb/v32de1/link/./rc_files/shared.sharedsandbox
lrwxr-xr-x   1 gsn      system        42 Sep  4 17:51 shared.submit -> /u/sb/v32de1/link/./rc_files/shared.submit
-rw-r--r--   1 gsn      system      1480 Jul 10 11:48 shared.tmpl
% 


T.RTitleUserPersonal
Name
DateLines