AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070531150702.125c5d1a@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<larry.scheer@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E02215809@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 31 May 2007 15:07:30 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>
Subject: Re: review cw_install changes
Message-ID: <20070531150730.356d9f5f@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E02215809@onstor-exch02.onstor.net>
References: <20070531141100.30618130@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E02215809@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yeah, same here with tar.  In fact, I've had tar catch things that I
was pretty surprised it caught compared to other programs like cp that
I don't think would have caught them.  Which is how I know that it does
some amount of verification.

So, I'll check that stuff in?

On Thu, 31 May 2007 14:21:49 -0700 "Larry Scheer"
<larry.scheer@onstor.com> wrote:

> No, I won't make you put in an extra verification step. I used my
> standalone install script to tests tar, cp and /usr/bin/install for
> reliability last fall. After hundreds (maybe even a thousand or so)
> passes using tar I never had a single failure. I have confidence in
> the version of tar that is in our BSD.
> 
> Glad you are prepared. I think it is time this sad song comes to an
> end.
> 
> Later,
> 
> Larry
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Thursday, May 31, 2007 2:11 PM
> To: Larry Scheer
> Subject: Re: review cw_install changes
> 
> On Thu, 31 May 2007 13:11:39 -0700 "Larry Scheer"
> <larry.scheer@onstor.com> wrote:
> 
> > > tar does a certain amount of verification.  is that not good
> > > enough
> > for
> > > you?  it's good enough for me.  there was no specification as to
> > > the thoroughness of the verification.  i rest my case.
> > 
> > > i could do something like this:
> > 
> > > tar xf tarball 2>tarerrors
> > > if [ -s tarerrors ] ; then
> > >    echo gaaaaaa
> > > fi
> > 
> > Or how about:
> > 
> > tar xf tarball 2>tarerrors
> > if [ -s tarerrors ] ; then
> >    echo "Gaaaack\! System fornication complete; time for a cigarette
> > and a beer."
> > else
> >    echo "Verification completed successfully. Have a nice day"
> > fi
> > 
> > Just seeing if I can make you laugh....
> > 
> > But, seriously...
> > It will be QA or CS who will squawk about the missing verification
> > phase since it is in the specification. I am just saying be prepared
> > for some blow-back once it is in QA. If Sandrine is doing the QA
> > work, she _will_ be looking for some form of verification success
> > message. 
> 
> I'm prepared.  Especially since I wrote the specification.  Nobody
> every said how or what as to details of the verification.  So at this
> point, I don't want to put in any more than I have, unless you make
> me.
> 
> The message is already in there, of course ~:^)
> 
> > > why don't i open a bug for all these changes and put the changes
> > > for verify_install.sh towards the bugs you sent me?
> > 
> > According to the notes in the defect and email I received from Raj,
> > those defects were waiting for the stand-alone install.
> > 
> > Opening a new defect for the silent reboots and listing the changes
> > to verify_install.sh as the "fix" seems more direct. I spoke to
> > Brian  De Forest and he doesn't have any problems with checking in
> > the fix with or without a defect. Having a defect for this specific
> > issue may help getting it in 2.2.3.
> > 
> > Later
> > 
> > Larry
> > 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Wednesday, May 30, 2007 5:51 PM
> > To: Larry Scheer
> > Subject: Re: review cw_install changes
> > 
> > On Wed, 30 May 2007 17:06:59 -0700 "Larry Scheer"
> > <larry.scheer@onstor.com> wrote:
> > 
> > > Makefile comments:
> > > Write cw_install.sh to $(PATH_TO_RELEASE)/etc .vs Tools. Don't
> > > pollute source trees with derived objects. Then you don't need the
> > > move.
> > 
> > fixed
> > 
> > > Line 562: Looking at how N_VERS is used in cw_install, you should
> > > use the make macro $(VER) which is the contents of
> > > nfx-tree/Tools/version. It doesn't have the 'b' character appended
> > > to it. So it will just be 3.0.0.0 or 2.2.3.0, etc. The version
> > > file in the release directory has a character 'b' appended to it
> > > to differentiate between bobcat and cheetah. (Cheetah's version
> > > file does not have the 'b'. I have no idea what it will be for
> > > cougar and bobcat linux.
> > 
> > fixed
> > 
> > > Cw_install.in comments:
> > > Line 106: hw_initials for Bobcat Linux will most likely be 'BL'
> > 
> > fixed.  buttload.  should be BC  gaaaah
> > 
> > > Line: 582: Missing preposition before "most cases." Perhaps is
> > > should be "in most cases." Or "for most cases."  (Whatever is your
> > > preferences (or most gooder English.)
> > 
> > ficked
> > 
> > > Line 596-597: Maybe it should say: "After a successful upgrade,
> > > your system will boot the software and you will have to log in
> > > again." Or it could be "When efficacious upgradation consummated
> > > system reboot will occur, necessitating login procedures upon
> > > completion of init level two."
> > 
> > uh
> > 
> > > Line 640: htype=`hw_initials` I think you meant
> > > hwtype=`hw_initials` because htype is unused.
> > 
> > fixed
> > 
> > > Lines 644-653: Unless you change the Makefile as mentioned above
> > > you can't use $N_VERS unmodified for anything but Cheetah builds.
> > > For bobcat (BSD) N_VERS would be set to 3.0.0.0b which breaks all
> > > of your default URLs.
> > 
> > I said fixed already
> > 
> > > The functional specification for the CW installation procedure
> > > has a requirement that the script "verifies the integrity of the
> > > copied files" (Pg. 9 of 14) and "verify the install before
> > > performing the reboot of the installed release." (Pg. 6 of 14) I
> > > did not see where the script did this.
> > 
> > tar does a certain amount of verification.  is that not good enough
> > for you?  it's good enough for me.  there was no specification as to
> > the thoroughness of the verification.  i rest my case.
> > 
> > i could do something like this:
> > 
> > tar xf tarball 2>tarerrors
> > if [ -s tarerrors ] ; then
> >     echo gaaaaaa
> > fi
> > 
> > > Changes to flash_install.sh can go with this change list or a
> > > separate one. It does make sense to check the file in with this
> > > change list.
> > 
> > yeah, they're just comments
> > 
> > > Verify_install.sh can go with this change, but I think a bug
> > > should be opened and filed for this fix and add this fix the
> > > Delorean release. It definitely should be back-ported to 2.2.3.0.
> > > Assigning a defect to it would expedite the process. (I would
> > > hope anyway.) Brian De Forest should be made aware of this fix.
> > 
> > why don't i open a bug for all these changes and put the changes for
> > verify_install.sh towards the bugs you sent me?
> > 
