From owner-freebsd-stable Sat Aug 9 20:00:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA28611 for stable-outgoing; Sat, 9 Aug 1997 20:00:26 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA28601 for ; Sat, 9 Aug 1997 20:00:13 -0700 (PDT) Received: (qmail 5483 invoked by uid 1000); 10 Aug 1997 03:00:12 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199708091710.KAA12784@austin.polstra.com> Date: Sat, 09 Aug 1997 20:00:12 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: John Polstra Subject: Re: broked stable Cc: stable@FreeBSD.ORG Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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