From owner-freebsd-current Tue Oct 12 17:36:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 9787714D5C for ; Tue, 12 Oct 1999 17:36:24 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial4-102.netcologne.de [195.14.233.102]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id CAA00114; Wed, 13 Oct 1999 02:36:20 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id CAA44765; Wed, 13 Oct 1999 02:36:42 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Wed, 13 Oct 1999 02:36:42 +0200 (CEST) Message-Id: <199910130036.CAA44765@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: peter.jeremy@alcatel.com.au Cc: van.woerkom@netcologne.de, freebsd-current@FreeBSD.ORG In-reply-to: <99Oct13.072458est.40328@border.alcanet.com.au> (message from Peter Jeremy on Wed, 13 Oct 1999 07:28:46 +1000) Subject: Re: Proper Whacking & Weeding Reply-To: van.woerkom@netcologne.de References: <199910121503.RAA02057@oranje.my.domain> <99Oct13.072458est.40328@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It might be useful if you documented exactly what you did. This is > likely to be a very popular topic for the next few months... Not quite possible, because when things started to look foobar I was not cool enough to keep logging. :) But I know some highlights of my tour: o My Last successful -current build was Sun Sep 19 19:18:42 CEST 1999 o Then I tried to rebuild on Tue Oct 5 17:49:53 CEST 1999 and got this one: ===> f77doc /usr/obj/usr/src/gnu/usr.bin/cc/f77doc created for /usr/src/gnu/usr.bin/cc/f77doc cd /usr/src/gnu/lib/libgcc; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPROFILE -DNOSHARED -B cleandir obj rm -f .depend /usr/obj/usr/src/gnu/lib/libgcc/GPATH /usr/obj/usr/src/gnu/lib/libgcc/GRTAGS /usr/obj/usr/src/gnu/lib/libgcc/GSYMS /usr/obj/usr/src/gnu/lib/libgcc/GTAGS echo '#include ' > config.h echo '#include ' >> config.h echo '#include "i386/xm-i386.h"' > tconfig.h echo '#include "i386/i386.h"' > tm.h echo '#include "i386/att.h"' >> tm.h echo '#include "i386/freebsd.h"' >> tm.h echo '#include "i386/perform.h"' >> tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. So I decided to wait some times, in case this was related to changes to gcc. o Next try was Sun Oct 10 12:55:50 CEST 1999 This time I had a look into freebsd-current and src/UPDATING before and noticed that I had to build a new kernel before. No problems. Kernel compiled, installed and booted. o Later, Sun Oct 10 13:38:40 CEST 1999 during make buildworld, I got this one: cc -O -pipe -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/make/arch.c In file included from /usr/include/sys/stat.h:50, from /usr/src/usr.bin/make/arch.c:97: /usr/include/sys/time.h:289: time.h: No such file or directory /usr/src/usr.bin/make/arch.c:100: ctype.h: No such file or directory /usr/src/usr.bin/make/arch.c:101: ar.h: No such file or directory /usr/src/usr.bin/make/arch.c:102: utime.h: No such file or directory /usr/src/usr.bin/make/arch.c:104: stdlib.h: No such file or directory In file included from /usr/src/usr.bin/make/arch.c:105: /usr/src/usr.bin/make/make.h:53: ctype.h: No such file or directory /usr/src/usr.bin/make/make.h:76: stdlib.h: No such file or directory In file included from /usr/src/usr.bin/make/make.h:80, from /usr/src/usr.bin/make/arch.c:105: /usr/src/usr.bin/make/lst.h:51: stdlib.h: No such file or directory /usr/src/usr.bin/make/arch.c: In function `ArchStatMember': /usr/src/usr.bin/make/arch.c:464: `SARMAG' undeclared (first use in this function) /usr/src/usr.bin/make/arch.c:464: (Each undeclared identifier is reported only once /usr/src/usr.bin/make/arch.c:464: for each function it appears in.) /usr/src/usr.bin/make/arch.c:468: storage size of `arh' isn't known /usr/src/usr.bin/make/arch.c:514: storage size of `sarh' isn't known /usr/src/usr.bin/make/arch.c:540: `ARMAG' undeclared (first use in this function) /usr/src/usr.bin/make/arch.c:552: sizeof applied to an incomplete type /usr/src/usr.bin/make/arch.c:553: `ARFMAG' undeclared (first use in this function) /usr/src/usr.bin/make/arch.c:621: sizeof applied to an incomplete type /usr/src/usr.bin/make/arch.c:623: sizeof applied to an incomplete type /usr/src/usr.bin/make/arch.c: In function `ArchFindMember': /usr/src/usr.bin/make/arch.c:785: `SARMAG' undeclared (first use in this function) /usr/src/usr.bin/make/arch.c:798: `ARMAG' undeclared (first use in this function) /usr/src/usr.bin/make/arch.c:814: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:815: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:818: sizeof applied to an incomplete type /usr/src/usr.bin/make/arch.c:819: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:819: `ARFMAG' undeclared (first use in this function) /usr/src/usr.bin/make/arch.c:819: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:826: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:834: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:834: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:844: sizeof applied to an incomplete type /usr/src/usr.bin/make/arch.c:890: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:890: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c:891: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c: In function `Arch_Touch': /usr/src/usr.bin/make/arch.c:924: storage size of `arh' isn't known /usr/src/usr.bin/make/arch.c:935: sizeof applied to an incomplete type /usr/src/usr.bin/make/arch.c: In function `Arch_TouchLib': /usr/src/usr.bin/make/arch.c:961: storage size of `arh' isn't known /usr/src/usr.bin/make/arch.c:962: storage size of `times' isn't known /usr/src/usr.bin/make/arch.c:968: sizeof applied to an incomplete type /usr/src/usr.bin/make/arch.c: In function `Arch_MTime': /usr/src/usr.bin/make/arch.c:1006: dereferencing pointer to incomplete type /usr/src/usr.bin/make/arch.c: In function `Arch_LibOODate': /usr/src/usr.bin/make/arch.c:1170: dereferencing pointer to incomplete type *** Error code 1 o Next try was weeding out /usr/include and /usr/share/misc (with the occasional cd /usr/src/include; make install) and a make world -DCLOBBER on Sun Oct 10 16:38:03 CEST 1999 that ended here: cc -O -pipe -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/make/compat.c In file included from /usr/src/usr.bin/make/compat.c:67: /usr/include/signal.h:80: syntax error before `*' /usr/include/signal.h:84: syntax error before `*' *** Error code 1 o Then came a make world -DNOTOOLS -DCLOBBER on Sun Oct 10 16:39:35 CEST 1999 that stopped here Processing hints file hints/freebsd.pl Writing Makefile for POSIX mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/auto mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/auto/POSIX cd ext/POSIX; make -B all PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl cp POSIX.pod /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/POSIX.pod cp POSIX.pm /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/POSIX.pm AutoSplitting /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/POSIX.pm (/usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/auto/POSIX) /usr/bin/miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/xsubpp -noprototypes -typemap /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/typemap -typemap typemap POSIX.xs >xstmp.c && mv xstmp.c POSIX.c cc -c -DSTRUCT_TM_HASZONE -DVERSION=\"1.02\" -DXS_VERSION=\"1.02\" -DPIC -fpic -I/usr/obj/usr/src/gnu/usr.bin/perl/perl POSIX.c In file included from POSIX.xs:31: /usr/include/signal.h:80: syntax error before `*' /usr/include/signal.h:84: syntax error before `*' *** Error code 1 o Can't remember what I did in what order exactly then, but it involved moving back to a tree that I believed to work (cvs update -D "14 Sep 1999"), diffing and copying headers in /usr/include and stuff in /usr/lib. Note that I kept the new kernel from Oct, 10th! Also some partial installs, when compilation hanged. Finally compilation went through. So I used that userland (that worked except for stuff like top and ps) to get the source tree from Oct, 11th and to finally compile that, after some obstacles. E.g. compilation broke off during build of kdump and ktrace. I finally hacked their makefiles to jump over them, to get a nearly complete Oct, 11th user land compiled. And it worked. Reboot and new kernel compilation worked too: -r-xr-xr-x 1 root wheel 1770088 Oct 11 22:51 kernel -r-xr-xr-x 1 root wheel 1770088 Oct 10 13:13 kernel.old -r-xr-xr-x 1 root wheel 1761443 Sep 19 21:11 kernel.ORANJE Same size, not bad. > As for obsolete cruft in the root and /usr filesystems, you could try > "rm -fr /" :-). Seriously, since installworld installs everything > with the current date, one way is to run "ls -ltr" on all all affected > directories and delete all files older than the installworld. In my case the old cruft had no effect during the last build, but then managed to sabotage the build of the latest system. Today, after a hint from Jörg Wunsch to use ktrace for resolving my trouble with emacs, I tried to recompile ktrace and kdump, ran again into trouble and then realized (after looking at the history with cd /usr/src/sys/netinet; cvs log ip_fil.h etc) ---------------------------- revision 1.8 date: 1999/10/10 15:09:53; author: peter; state: dead; lines: +1 -1 Nuke the old antique copy of ipfilter from the tree. This is old enough to be dangerous. It will better serve us as a port building a KLD, ala SKIP. The hooks are staying although it would be better to port and use the NetBSD pfil interface rather than have custom hooks. ---------------------------- that these headers ip_compat.h ip_fil.h ip_frag.h ip_nat.h ip_proxy.h ip_state.h ipl.h were obsolete and their existence prevented the kdump build. And you can't nuke /usr/include in advance, as you need it to build the new system. > I have had a couple of occurrences where my checked-out source tree > got out of step with my CVS tree (I'm not sure how this happened). > My solution here is to occasionally do a checkout into a temporary > tree and compare it with my active tree. > (An alternative would be to squirrel away my local patches and blow > away the active tree). I really wonder how our hardcore coders manage large sets of patches during their development phase. Sounds like a job for cvs, or? AFAIK, in cvs theory I would have my local cvs repository and would operate it with at least two branches. A vendor branch, were I would import the stuff I get from vendor FreeBSD.org and the main trunk, were I grow my version of the source tree. So I could use cvsup to checkout the latest tree from FreeBSD.org into some directory and import that one with a cvs import command. No clue how long that would take with such a large tree. If it is comparable to a cvs update, it will take 30min-1h for all stuff (doc,ports,src,www) on my box. I also can't say how many conflicts will arise, if that new stuff hits local modifications. If I would import on a daily base, would I need to resolve conflicts again and again? Anyway. That would give me the sources only. [Warning: long blurb - will get recycled see below :) ] One of the best things that happened to me in the last months regarding FreeBSD development was switching CVSup usage from mirroring the latest tree (thus having only the head revision for every source) to mirroring the CVS archives at FreeBSD.org This gives me access to a) all revisions of a file, and -also very important- b) access to the checkin comments of the commiters. The first case is what made me originally switch. I use Hellmuth Michaelis i4b package to connect to the Internet via ISDN. This is usually working so excellent that I never took the time to install ISDN drivers to that Windows 95 system that is also on my disks. However FreeBSD and i4b were changing in a way last year, that often, after updating a nice working source tree over the Internet and recompiling I ended up with a system that was (among other things) broken in a way that it was not able anymore to connect to the net. Bad situation because I had only the latest tree on my disk, and could not revert easily (= via the net) to a working tree. So I usually installed an older FreeBSD version from CD-ROM then and started over. That was quite an act sometimes (sd->da, aout->elf..) Then I realized that I need the CVS repository on my box, and with help from John Polstra I configured CVSup to mirror it. Since then I can use cvs log and cvs status to see the history and read the committer's comments. Very useful. Drawback is speed. While CVSup mirrors the CVS repository quite fast I now need an additional cvs update to sync my source tree with the CVS repository. And that is quite slow. (But I am working on a program that will speed up this process) [end of blurb - back to administering patches] So, how to get the comments into the cvs repository? Possible sources are - the commit messages from the cvs-all mailing list (local copy, or accessed from www.freebsd.org) - the FreeBSD CVS repository itself (local mirror as described above, or accessed from the anoncvs server at FreeBSD.org) It should be possible building such a system, with lots of duct tape. Question is -and that is the reason I went into such detail here- is this a too complicated solution for managing an individual tree while staying in contact with the main tree, or might it be useful? I hope for some criticism by the folks here, and will experiment further and hope to finally write it up. Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message