[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines
|
---|