Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 09 Aug 1997 20:00:12 -0700 (PDT)
From:      Simon Shapiro <Shimon@i-Connect.Net>
To:        John Polstra <jdp@polstra.com>
Cc:        stable@FreeBSD.ORG
Subject:   Re: broked stable
Message-ID:  <XFMail.970809200012.Shimon@i-Connect.Net>
In-Reply-To: <199708091710.KAA12784@austin.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Hi John Polstra;  On 09-Aug-97 you wrote: 
> > please point to me (yes, again...) the flaw in my procedure:
> > 
> > 
> > My cvsup file:
> > 
> > *default base=/usr/local/etc/cvsup
> > *default prefix=/Archives/FreeBSD/FreeBSD-CVS
> > *default release=cvs
> > *default host=sup.FreeBSD.org
> 
> "sup.freebsd.org" works currently, but it's an obsolescent hostname.
> I'd suggest using the equivalent "cvsup2.freebsd.org" instead.

Changed.  Will that change the contents of the archive?  :-)

Do you want another mirror?  I have a host I could put to the task,
on a T1 with excellent connectivity. 

> > *default hostbase=/home
> 
> This line is waaaaay obsolete.  It's ignored, so you might as well
> get rid of it.

Gone.

> I also noticed from the server logs that you're 1 revision behind in
> your CVSup client.  Generally I try to make new revisions better in
> some way than old ones. :-)

Done.  Trying to track all these pieces is a full time job.

> > My cvsup command line:
> > 
> > cd /usr/local/etc/cvsup
> > rm -rf sup
> 
> WHOA!  Why on earth are you doing that?!  You are _guaranteeing_
> that files removed from the repository won't get removed on your own
> system.  There's no telling how much extra cruft you have lying
> around as a result.

I forgot to add a rm -rf on the archive itself.  This is my version 
of a reset button.  When things go crazy and all i get is ``doesn't
happen to me, must be you'', I believe that and make shure that my 
``me'' is as pristine as possible.  I know it is destructive and
wasteful.  but three repeated failure indicate a problem.

> > Then I do :
> > 
> > rm -rf /usr/src/2.2/src
> > rm -rf /usr/obj/usr
> > cd /usr/src/2.2
> > cvs checkout -rRELENG_2_2 src
> > cd ..
> > ln -s /usr/src/2.2/src/* .
> 
> What's the point of creating all those links in the parent
> directory?  Never mind, I probably don't want to know. :-)

Simple.  I can have multiple trees compiled this way.  I have a FreeBSD
tree which produces a ``stock'' release.  An Atlas tree that contains
local, employer's configuration, a Test tree that includes recent
checkouts, a Development tree that contains all my, unchecked-in
changes, etc.  ``cd /usr/src; rm *; ln -s ProperTree/* .'' allows us
to build any tree we want.  Having /usr/src on a Raid5 filesystem, and
/usr/obj on a RAID-0 also speeds things up nicely while providing a very
safe and reproducable environment.  BTW, the CVS tree is on another
filesystem.  So is the local RCS, so is the local CVS.  All we backup is
the RCS, and the CVS.  The entire system is easily reprodcable this
way.

SysV was easier in that regard.  All pathnames have ${ROOT} prefixing
them, along with ${CPU} and ${ARCH} where appropriate.  Quick change to
these would build almost any release on any platform.

> > It must be a flawed procedure because it works only 60% of the
> > time.  Different days produce different errors (no joke).  Monday,
> > it was an html file with the wrong format.  Turns out to be a 3.0
> > file that somehow ended up in the 2.2 tree.
> 
> Erm ... have you run fsck lately?  Have you been mounting your disks
> async?

Yup.  Clean as a whistle.  Never.  I am stupid, not sucidal :-)

> > Today, the make depend part of make world blows up because the tty
> > command does not get built/installed in
> > /usr/obj/usr/src.2.2/src/tmp/usr/bin.  Yes, I started the build,
> > and then snuck it in.
> 
> You can "sneak things in" and get away with it sometimes, but it
> makes it virtually impossible for anybody else to help with whatever
> mysterious problems crop up.

I know that.  I was faced with a broken process and wanted to verify
that the ``tty: not found'' is the ONLY problem.  It is.  The PATH is
set to a number of /usr/obj/where_the_source_tree_is/tmp places which
get populated.  The tty command is NOT shown to be made anywhere in the
make output and therefore not installed there.  It broke the build.
Sneaking it in (which IS adirty trick) both confirmed it and allowed
the build to complete.

> > BTW, on normal days, I do not destroy the whole world.  I just run
> > cvsup a couple of times to make sure I am current, do cvs update
> > -P -d and make world.
> 
> I would also add "-r RELENG_2_2" even though the manual says you
> don't have to.  There have been credible reports that it makes a
> difference.

Yes it makes a difference.  Not all the time.  Sometimes.  The source 
tree is too complex for me to try and decypher, but you are welcome to
login and brouse.

> > The difference in reliability and predictability of the process is
> > not very visible to me.
> 
> Right.  You shouldn't ever have to destroy your src tree and do a
> full checkout.  A cvs update should be all you need.

I agree with ``should not '' and have to sadly report that it sometimes
``does''.  This time it did not, but twice before, this was all that
worked.

> I don't know what's causing your problems, but your repository
> almost certainly has some extra files in it, because of your "rm -rf
> sup" command.  There is no easy way to get rid of them or find out
> what they are except by running find|sort on a good repository and on
> your own, and comparing the lists.  Or delete your whole repository
> and fetch it again. :-O

I did, yesterday.  Also deleted the entire 2.2 source tree.  The tty
problem is still there.  Not on current though.  Current missed a file
that showed up later.

> There is also some possibility that your problems could be explained
> by corrupted filesystems.

Nothing fsck can tell me.  There is no detected corruption from access
or use, either.

> Sorry, that's all I have to offer.

Which is a lot.  Thanx!

Simon




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970809200012.Shimon>