From owner-freebsd-current Sun Sep 1 00:44:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA13084 for current-outgoing; Sun, 1 Sep 1996 00:44:22 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA13078 for ; Sun, 1 Sep 1996 00:44:15 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id JAA12794 for current@freebsd.org; Sun, 1 Sep 1996 09:30:21 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.5/8.7.3) with SMTP id JAA00851 for ; Sun, 1 Sep 1996 09:35:32 +0200 (MET DST) Date: Sun, 1 Sep 1996 09:35:32 +0200 (MET DST) From: Andreas Klemm To: current@freebsd.org Subject: cvsup question, src/tools not updated, make release trouble Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ! When trying to roll my own release of FreeBSD-current (to intall a fresh copy of -current on a 2nd computer), I detected some problems on the way ... a) make release doesn't run through, stops when trying to copy manpages in the beginning. I think the migration of tcl into the contrib tree might be the culprit here. b) When getting cvs via cvsup I dont get the tools directory ... Why ? c) Why is everything so difficult now ... libtcl went to /usr/src/contrib, but still there are files in /usr/src/lib/libtcl ... Is that really needed ?! /usr/src/lib/libtcl/tclConfig.sh: # tclConfig.sh -- # # This shell script (for sh) is generated automatically by Tcl's # configure script. It will create shell variables for most of [...] Here the error message from a make release: -rw-r--r-- 1 root wheel 99667 1 Sep 07:58 /usr/src/release.log ===> lib/libscsi install -C -o bin -g bin -m 444 /usr/src/lib/libscsi/scsi.h /local/release/usr/include install -c -o bin -g bin -m 444 libscsi.a /local/release/usr/lib install -c -o bin -g bin -m 444 libscsi.so.2.0 /local/release/usr/lib install -c -o bin -g bin -m 444 scsi.3.gz /local/release/usr/share/man/man3 /local/release/usr/share/man/man3/scsireq_buff_decode.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsireq_build.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsireq_decode.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsireq_encode.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsireq_enter.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsireq_new.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsireq_reset.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/SCSIREQ_ERROR.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsi_open.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsi_debug.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz /local/release/usr/share/man/man3/scsi_debug_output.3.gz -> /local/release/usr/share/man/man3/scsi.3.gz ===> lib/libskey install -C -o bin -g bin -m 444 /usr/src/lib/libskey/skey.h /local/release/usr/include install -c -o bin -g bin -m 444 libskey.a /local/release/usr/lib install -c -o bin -g bin -m 444 libskey.so.2.0 /local/release/usr/lib install -c -o bin -g bin -m 444 skey.access.5.gz /local/release/usr/share/man/man5 install -c -o bin -g bin -m 444 skey.1.gz /local/release/usr/share/man/man1 ===> lib/libss install -C -o bin -g bin -m 444 /usr/src/lib/libss/ss.h /local/release/usr/include/ss install -C -o bin -g bin -m 444 /usr/src/lib/libss/copyright.h /local/release/usr/include/ss/mit-sipb-copyright.h install -C -o bin -g bin -m 444 ss_err.h /local/release/usr/include/ss install -c -o bin -g bin -m 444 libss.a /local/release/usr/lib install -c -o bin -g bin -m 444 libss.so.2.0 /local/release/usr/lib ===> lib/libtcl install -C -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/generic/tcl.h /local/release/usr/include install -c -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/library/[a-z]* /local/release//usr/libdata/tcl install -c -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/unix/tclAppInit.c /local/release//usr/libdata/tcl install -c -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/doc/man.macros /local/release/usr/share/tmac/tcl.macros install -c -o bin -g bin -m 444 /usr/src/lib/libtcl/tclConfig.sh /local/release//usr/libdata/tcl install -C -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/unix/tclUnixPort.h /local/release/usr/include/tcl/unix/tclUnixPort.h install -C -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/generic/tclRegexp.h /local/release/usr/include/tcl/generic/tclRegexp.h install -C -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/generic/tclPort.h /local/release/usr/include/tcl/generic/tclPort.h install -C -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/generic/tclInt.h /local/release/usr/include/tcl/generic/tclInt.h install -C -o bin -g bin -m 444 /usr/src/lib/libtcl/../../contrib/tcl/generic/patchlevel.h /local/release/usr/include/tcl/generic/patchlevel.h install -c -o bin -g bin -m 444 libtcl.a /local/release/usr/lib install -c -o bin -g bin -m 444 libtcl.so.75.0 /local/release/usr/lib /local/release/usr/lib/libtcl75.so.1.0 -> /local/release/usr/lib/libtcl.so.75.0 /local/release/usr/lib/libtcl75.a -> /local/release/usr/lib/libtcl.a install -c -o bin -g bin -m 444 Tcl.n.gz after.n.gz append.n.gz array.n.gz bgerror.n.gz break.n.gz case.n.gz catch.n.gz cd.n.gz clock.n.gz close.n.gz concat.n.gz continue.n.gz eof.n.gz error.n.gz eval.n.gz exec.n.gz exit.n.gz expr.n.gz fblocked.n.gz fconf igure.n.gz file.n.gz fileevent.n.gz filename.n.gz flush.n.gz for.n.gz foreach.n.gz format.n.gz gets.n.gz glob.n.gz global.n.gz history.n.gz if.n.gz incr.n.gz info.n.gz interp.n.gz join.n.gz lappend.n.gz library.n.gz lindex.n.gz linsert.n.gz list.n.gz llen gth.n.gz load.n.gz lrange.n.gz lreplace.n.gz lsearch.n.gz lsort.n.gz open.n.gz package.n.gz pid.n.gz pkgMkIndex.n.gz proc.n.gz puts.n.gz pwd.n.gz read.n.gz regexp.n.gz regsub.n.gz rename.n.gz return.n.gz scan.n.gz seek.n.gz set.n.gz socket.n.gz source.n.g z split.n.gz string.n.gz subst.n.gz switch.n.gz tclvars.n.gz tell.n.gz time.n.gz trace.n.gz unknown.n.gz unset.n.gz update.n.gz uplevel.n.gz upvar.n.gz vwait.n.gz while.n.gz /local/release/usr/share/man/mann install -c -o bin -g bin -m 444 AddErrInfo.3.gz AllowExc.3.gz AppInit.3.gz AssocData.3.gz Async.3.gz BackgdErr.3.gz Backslash.3.gz CallDel.3.gz CmdCmplt.3.gz Concat.3.gz CrtChannel.3.gz CrtChnlHdlr.3.gz CrtCloseHdlr.3.gz CrtCommand.3.gz CrtFileHdlr.3.gz C rtInterp.3.gz CrtMathFnc.3.gz CrtModalTmt.3.gz CrtSlave.3.gz CrtTimerHdlr.3.gz CrtTrace.3.gz DString.3.gz DetachPids.3.gz DoOneEvent.3.gz DoWhenIdle.3.gz Eval.3.gz Exit.3.gz ExprLong.3.gz FindExec.3.gz GetFile.3.gz GetInt.3.gz GetOpnFl.3.gz GetStdChan.3.g z Hash.3.gz Interp.3.gz LinkVar.3.gz Notifier.3.gz OpenFileChnl.3.gz OpenTcp.3.gz PkgRequire.3.gz Preserve.3.gz PrintDbl.3.gz RecordEval.3.gz RegExp.3.gz SetErrno.3.gz SetRecLmt.3.gz SetResult.3.gz SetVar.3.gz Sleep.3.gz SplitList.3.gz StaticPkg.3.gz StrM atch.3.gz Tcl_Main.3.gz TraceVar.3.gz Translate.3.gz UpVar.3.gz /local/release/usr/share/man/man3 /local/release/usr/share/man/man3/Tcl_SetErrorCode.3.gz -> /local/release/usr/share/man/man3/Tcl_AddErrorInfo.3.gz ln: /local/release/usr/share/man/man3/Tcl_AddErrorInfo.3.gz: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Sun Sep 1 03:14:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA18208 for current-outgoing; Sun, 1 Sep 1996 03:14:26 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA18197 for ; Sun, 1 Sep 1996 03:14:15 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id MAA16298 for current@freebsd.org; Sun, 1 Sep 1996 12:00:39 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.5/8.7.3) with SMTP id LAA02668 for ; Sun, 1 Sep 1996 11:32:56 +0200 (MET DST) Date: Sun, 1 Sep 1996 11:32:55 +0200 (MET DST) From: Andreas Klemm To: current@freebsd.org Subject: bisdn works great, here a sample netstat 10 during ftp over 64kBit , link Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ! Here a really fast connection to my ISP using bisdn... andreas@klemm{1002} ~ netstat -I ipi0 10 input (ipi0) output packets errs bytes packets errs bytes colls 52 0 78000 50 0 3000 0 52 0 78000 50 0 3000 0 53 0 79500 50 0 3000 0 52 0 78000 50 0 3000 0 52 0 78000 50 0 3000 0 53 0 79500 50 0 3000 0 52 0 78000 50 0 3000 0 52 0 78000 50 0 3000 0 53 0 79500 50 0 3000 0 52 0 78000 50 0 3000 0 52 0 78000 51 0 3060 0 53 0 79500 50 0 3000 0 52 0 78000 50 0 3000 0 52 0 78000 50 0 3000 0 53 0 79500 50 0 3000 0 Yeah, it's about 7.91 KByte/sec. Is there any reason, why we don't commit bisdn 0.97 to FreeBSD-current ? I'd love to see this, ... -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Sun Sep 1 06:00:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA25803 for current-outgoing; Sun, 1 Sep 1996 06:00:27 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA25797 for ; Sun, 1 Sep 1996 06:00:20 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.7.5/8.7.3) id NAA03563; Sun, 1 Sep 1996 13:00:42 GMT From: Adam David Message-Id: <199609011300.NAA03563@veda.is> Subject: Re: bin/1560: To: ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Sun, 1 Sep 1996 13:00:39 +0000 (GMT) Cc: bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199609010021.EAA04448@nagual.ru> from "[______ ______]" at "Sep 1, 96 04:21:08 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > /usr/include/termcap.h declares tputs() as type void, whereas in > > > > /usr/include/*curses.h it says an integer is returned. This results > > > > in a type conflict and programs don't compile. > > > > > > Someone "cleaned up" the termcap version. It used to return a garbage > > > int. > > > > > > Bruce > > > > > > > Uh, this means *curses needs to be brought into sync, right? > > Ncurses declare it as void too. Old curses+termlib will be removed > in future. really? $ rm -r /usr/include; make hierarchy includes $ grep --eyeball tputs /usr/include/*.h /usr/include/curses.h:int tputs __P((const char *, int, void (*)(int))); /usr/include/curses.h:int tputs __P((const char *, int, int (*)(int))); /usr/include/ncurses.h:extern int tputs(const char *,int,int (*)(int)); /usr/include/term.h:extern int del_curterm __P((TERMINAL *)), tputs __P((const char *, int, int (*)(int))); /usr/include/termcap.h:extern void tputs __P((const char *, int, int (*)(int))); Adam From owner-freebsd-current Sun Sep 1 06:57:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA27019 for current-outgoing; Sun, 1 Sep 1996 06:57:22 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA27014 for ; Sun, 1 Sep 1996 06:57:19 -0700 (PDT) Received: by sovcom.kiae.su id AA29348 (5.65.kiae-1 ); Sun, 1 Sep 1996 16:53:14 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sun, 1 Sep 96 16:53:14 +0300 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id RAA03488; Sun, 1 Sep 1996 17:53:08 +0400 (MSD) Message-Id: <199609011353.RAA03488@nagual.ru> Subject: Re: bin/1560: In-Reply-To: <199609011300.NAA03563@veda.is> from "Adam David" at "Sep 1, 96 01:00:39 pm" To: adam@veda.is (Adam David) Date: Sun, 1 Sep 1996 17:53:07 +0400 (MSD) Cc: bde@zeta.org.au, current@FreeBSD.org From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > > /usr/include/termcap.h declares tputs() as type void, whereas in > > > > > /usr/include/*curses.h it says an integer is returned. This results > > > > > in a type conflict and programs don't compile. > > > > > > > > Someone "cleaned up" the termcap version. It used to return a garbage > > > > int. > > > > > > > > Bruce > > > > > > > > > > Uh, this means *curses needs to be brought into sync, right? > > > > Ncurses declare it as void too. Old curses+termlib will be removed > > in future. > > really? > ... > /usr/include/ncurses.h:extern int tputs(const char *,int,int (*)(int)); ... Old ncurses will be replaced with new one. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Sun Sep 1 09:02:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA02039 for current-outgoing; Sun, 1 Sep 1996 09:02:11 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA02033 for ; Sun, 1 Sep 1996 09:02:07 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA11004; Mon, 2 Sep 1996 01:56:14 +1000 Date: Mon, 2 Sep 1996 01:56:14 +1000 From: Bruce Evans Message-Id: <199609011556.BAA11004@godzilla.zeta.org.au> To: ache@nagual.ru, adam@veda.is Subject: Re: bin/1560: Cc: bde@zeta.org.au, current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> > > > /usr/include/termcap.h declares tputs() as type void, whereas in >> > ... >> > Uh, this means *curses needs to be brought into sync, right? >> >> Ncurses declare it as void too. Old curses+termlib will be removed >> in future. >Too much trouble. You would have to increment the libc.so's major number >:-). Something might be depending on tputs() to return a value (perhaps >even a garbage value) like it was declared to. >really? >$ rm -r /usr/include; make hierarchy includes >$ grep --eyeball tputs /usr/include/*.h >/usr/include/curses.h:int tputs __P((const char *, int, void (*)(int))); >/usr/include/curses.h:int tputs __P((const char *, int, int (*)(int))); >/usr/include/ncurses.h:extern int tputs(const char *,int,int (*)(int)); >/usr/include/term.h:extern int del_curterm __P((TERMINAL *)), tputs __P((const char *, int, int (*)(int))); >/usr/include/termcap.h:extern void tputs __P((const char *, int, int (*)(int))); These are for `old' curses. curses_termin.3 gives an inconsistent prototype for tputs(). It has the function type wrong this time. I fixed this but didn't commit the fix because old curses was to go away RSN :-). Bruce From owner-freebsd-current Sun Sep 1 10:29:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06537 for current-outgoing; Sun, 1 Sep 1996 10:29:52 -0700 (PDT) Received: from moonpie.w8hd.org (moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA06530 for ; Sun, 1 Sep 1996 10:29:49 -0700 (PDT) Received: from localhost (kimc@localhost) by moonpie.w8hd.org (8.7.5/8.6.12) with SMTP id NAA00203 for ; Sun, 1 Sep 1996 13:29:48 -0400 (EDT) X-Authentication-Warning: moonpie.w8hd.org: kimc owned process doing -bs Date: Sun, 1 Sep 1996 13:29:48 -0400 (EDT) From: Kim Culhan To: current@FreeBSD.org Subject: -current build failure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Now this build failure on -current sup'd at about 1400 UTC this date: mkdep -f .depend -a -I. -I/usr/src/usr.bin/dig/../../contrib/bind -I/usr/src/usr.bin/dig/../../contrib/bind/include -DUSE_OPTIONS_H /usr/src/usr.bin/dig/dig.c /usr/src/usr.bin/dig/../../contrib/bind/tools/nslookup/list.c /usr/src/usr.bin/dig/../../contrib/bind/tools/nslookup/subr.c /usr/src/usr.bin/dig/../../contrib/bind/tools/nslookup/debug.c /usr/src/usr.bin/dig/../../contrib/bind/tools/nslookup/send.c /usr/src/usr.bin/dig/dig.c:167: res.h: No such file or directory mkdep: compile failed. *** Error code 1 Stop. What would be a good method to resume the build? regards kim -- kimc@w8hd.org From owner-freebsd-current Sun Sep 1 15:39:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA23934 for current-outgoing; Sun, 1 Sep 1996 15:39:41 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA23924 for ; Sun, 1 Sep 1996 15:39:39 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id PAA12163; Sun, 1 Sep 1996 15:39:31 -0700 (PDT) Message-Id: <199609012239.PAA12163@austin.polstra.com> To: andreas@klemm.gtn.com Cc: current@freebsd.org Subject: Re: cvsup question, src/tools not updated, make release trouble In-reply-to: Date: Sun, 01 Sep 1996 15:39:31 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > b) When getting cvs via cvsup I dont get the tools directory ... Why ? It's not a CVSup problem. It's because the mirror site you're using hasn't updated his sup configuration files recently. The tools directory was recently added to the "src-etc" collection on freefall. But some of the other mirrors have not yet updated the necessary files on their systems. I know which mirror you're using. I will contact the administrator and ask him to fix it. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Sun Sep 1 16:34:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA28041 for current-outgoing; Sun, 1 Sep 1996 16:34:52 -0700 (PDT) Received: from moonpie.w8hd.org (moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA28035 for ; Sun, 1 Sep 1996 16:34:49 -0700 (PDT) Received: from localhost (kimc@localhost) by moonpie.w8hd.org (8.7.5/8.6.12) with SMTP id TAA00667 for ; Sun, 1 Sep 1996 19:34:47 -0400 (EDT) X-Authentication-Warning: moonpie.w8hd.org: kimc owned process doing -bs Date: Sun, 1 Sep 1996 19:34:47 -0400 (EDT) From: Kim Culhan To: current@FreeBSD.org Subject: Current build failure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Its been some time since -current was buildable, now this: mkdep -f .depend -a -I/usr/src/usr.bin/locate/code/../locate /usr/src/usr.bin/ locate/code/locate.code.c ===> usr.bin/locate/locate rm -f .depend mkdep -f .depend -a -I. -DMMAP /usr/src/usr.bin/locate/locate/util.c /usr/src/ usr.bin/locate/locate/locate.c /usr/src/usr.bin/locate/locate/locate.c:355: fastfind.c: No such file or directory /usr/src/usr.bin/locate/locate/locate.c:357: fastfind.c: No such file or directory /usr/src/usr.bin/locate/locate/locate.c:364: fastfind.c: No such file or directory /usr/src/usr.bin/locate/locate/locate.c:366: fastfind.c: No such file or directory mkdep: compile failed. *** Error code 1 This was found by loading the 2.2-960801-SNAP, then sup'ing -current, then 'make bootstrap' (dunno if thats to be assumed) and then make world. Where am I going wrong? regards kim -- kimc@w8hd.org From owner-freebsd-current Sun Sep 1 17:51:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA02510 for current-outgoing; Sun, 1 Sep 1996 17:51:58 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA02505 for ; Sun, 1 Sep 1996 17:51:55 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA20490; Mon, 2 Sep 1996 00:51:43 GMT Date: Mon, 2 Sep 1996 09:51:43 +0900 (JST) From: Michael Hancock To: Kim Culhan cc: current@FreeBSD.org Subject: Re: Current build failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 1 Sep 1996, Kim Culhan wrote: > /usr/src/usr.bin/locate/locate/locate.c:355: fastfind.c: No such file or > directory Check the obvious first. Double check your supfiles. Re-read the docs. Watch cvs-all. Study the make targets and try building some of the key subtargets. It's at least a step toward learning the build process. Keep supping and making (once a week or once a day), current is often not buildable. If you're new to current track it for at least a couple of months doing all of the above before posting to current. Regards and good luck, Mike Hancock From owner-freebsd-current Sun Sep 1 18:19:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA03134 for current-outgoing; Sun, 1 Sep 1996 18:19:33 -0700 (PDT) Received: from moonpie.w8hd.org (moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA03129 for ; Sun, 1 Sep 1996 18:19:30 -0700 (PDT) Received: from localhost (kimc@localhost) by moonpie.w8hd.org (8.7.5/8.6.12) with SMTP id VAA00781; Sun, 1 Sep 1996 21:19:23 -0400 (EDT) X-Authentication-Warning: moonpie.w8hd.org: kimc owned process doing -bs Date: Sun, 1 Sep 1996 21:19:23 -0400 (EDT) From: Kim Culhan To: Michael Hancock cc: current@FreeBSD.org Subject: Re: Current build failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Sep 1996, Michael Hancock wrote: > On Sun, 1 Sep 1996, Kim Culhan wrote: > > > /usr/src/usr.bin/locate/locate/locate.c:355: fastfind.c: No such file or > > directory > > Check the obvious first. [deleted] Does this mean noone else is having trouble building -current? kim -- kimc@w8hd.org From owner-freebsd-current Sun Sep 1 18:27:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA03319 for current-outgoing; Sun, 1 Sep 1996 18:27:23 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA03314 for ; Sun, 1 Sep 1996 18:27:20 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id BAA20744; Mon, 2 Sep 1996 01:27:13 GMT Date: Mon, 2 Sep 1996 10:27:13 +0900 (JST) From: Michael Hancock To: Kim Culhan cc: current@FreeBSD.org Subject: Re: Current build failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 1 Sep 1996, Kim Culhan wrote: > On Mon, 2 Sep 1996, Michael Hancock wrote: > > > On Sun, 1 Sep 1996, Kim Culhan wrote: > > > > > /usr/src/usr.bin/locate/locate/locate.c:355: fastfind.c: No such file or > > > directory > > > > Check the obvious first. > > [deleted] > > Does this mean noone else is having trouble building -current? no. yes. hint, [deleted] From owner-freebsd-current Sun Sep 1 19:01:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04304 for current-outgoing; Sun, 1 Sep 1996 19:01:39 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA04299 for ; Sun, 1 Sep 1996 19:01:36 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id TAA13730; Sun, 1 Sep 1996 19:01:26 -0700 (PDT) To: Kim Culhan cc: Michael Hancock , current@FreeBSD.org Subject: Re: Current build failure In-reply-to: Your message of "Sun, 01 Sep 1996 21:19:23 EDT." Date: Sun, 01 Sep 1996 19:01:26 -0700 Message-ID: <13728.841629686@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > [deleted] > > Does this mean noone else is having trouble building -current? I just built it from this morning's CVS tree - worked a treat. Jordan From owner-freebsd-current Sun Sep 1 19:04:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04407 for current-outgoing; Sun, 1 Sep 1996 19:04:31 -0700 (PDT) Received: from moonpie.w8hd.org (moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA04399 for ; Sun, 1 Sep 1996 19:04:27 -0700 (PDT) Received: from localhost (kimc@localhost) by moonpie.w8hd.org (8.7.5/8.6.12) with SMTP id WAA00856; Sun, 1 Sep 1996 22:04:11 -0400 (EDT) X-Authentication-Warning: moonpie.w8hd.org: kimc owned process doing -bs Date: Sun, 1 Sep 1996 22:04:11 -0400 (EDT) From: Kim Culhan To: "Jordan K. Hubbard" cc: Michael Hancock , current@FreeBSD.org Subject: Re: Current build failure In-Reply-To: <13728.841629686@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 1 Sep 1996, Jordan K. Hubbard wrote: > I just built it from this morning's CVS tree - worked a treat. Hmm.. how am I getting different bits then? kim -- kimc@w8hd.org From owner-freebsd-current Sun Sep 1 19:11:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04634 for current-outgoing; Sun, 1 Sep 1996 19:11:18 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA04629; Sun, 1 Sep 1996 19:11:13 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id TAA13845; Sun, 1 Sep 1996 19:11:12 -0700 (PDT) To: current@freebsd.org cc: bde@freebsd.org Subject: Anyone mind if I remove the following braindamage from test(1)? Date: Sun, 01 Sep 1996 19:11:12 -0700 Message-ID: <13843.841630272@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk root@time-> [ -d /tmp ] && echo Yup, its a directory Yup, its a directory root@time-> [ -d ] && echo Yup, its a directory Yup, its a directory Clearly, as Bruce has already noted in other email, the second form is clearly bogus and should generate a usage message of some sort since -d obviously takes an argument. Is there any POSIX weirdness which mandates that test not do proper argument checking? Jordan From owner-freebsd-current Sun Sep 1 19:11:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04653 for current-outgoing; Sun, 1 Sep 1996 19:11:38 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA04648 for ; Sun, 1 Sep 1996 19:11:36 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id TAA13860; Sun, 1 Sep 1996 19:11:28 -0700 (PDT) To: Kim Culhan cc: Michael Hancock , current@FreeBSD.org Subject: Re: Current build failure In-reply-to: Your message of "Sun, 01 Sep 1996 22:04:11 EDT." Date: Sun, 01 Sep 1996 19:11:28 -0700 Message-ID: <13858.841630288@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk You tell us! :-) > > > On Sun, 1 Sep 1996, Jordan K. Hubbard wrote: > > > I just built it from this morning's CVS tree - worked a treat. > > Hmm.. how am I getting different bits then? > > kim > > -- > kimc@w8hd.org > > From owner-freebsd-current Sun Sep 1 19:26:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA05139 for current-outgoing; Sun, 1 Sep 1996 19:26:27 -0700 (PDT) Received: from white.dogwood.com (root@white.dogwood.com [140.174.96.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA05132 for ; Sun, 1 Sep 1996 19:26:24 -0700 (PDT) Received: (from dave@localhost) by white.dogwood.com (8.7.5/8.7.1) id TAA17393 ; Sun, 1 Sep 1996 19:26:12 -0700 (PDT) From: Dave Cornejo Message-Id: <199609020226.TAA17393@white.dogwood.com> Subject: Re: Current build failure To: kimc@w8hd.org (Kim Culhan) Date: Sun, 1 Sep 1996 19:26:11 -0700 (PDT) Cc: michaelh@cet.co.jp, current@FreeBSD.org In-Reply-To: from "Kim Culhan" at "Sep 1, 96 09:19:23 pm" Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Kim Culhan wrote: > On Mon, 2 Sep 1996, Michael Hancock wrote: > > > On Sun, 1 Sep 1996, Kim Culhan wrote: > > > > > /usr/src/usr.bin/locate/locate/locate.c:355: fastfind.c: No such file or > > > directory > > > > Check the obvious first. > > [deleted] > > Does this mean noone else is having trouble building -current? > > kim I edited locate.c and replaced all occurances of #include with #include "fastfind.c" to get it to compile. Isn't this correct for files from the local directory? -- Dave Cornejo - Dogwood Media, Fremont, California From owner-freebsd-current Sun Sep 1 20:00:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA06661 for current-outgoing; Sun, 1 Sep 1996 20:00:51 -0700 (PDT) Received: from hp.com (hp.com [15.255.152.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA06656 for ; Sun, 1 Sep 1996 20:00:49 -0700 (PDT) Received: from fakir.india.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA159583241; Sun, 1 Sep 1996 20:00:45 -0700 Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA116635064; Mon, 2 Sep 1996 08:31:04 +0500 Message-Id: <199609020331.AA116635064@fakir.india.hp.com> To: freebsd-current@freebsd.org Subject: ddb now requires sio Date: Mon, 02 Sep 1996 08:31:04 +0500 From: A JOSEPH KOSHY Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk `option DDB' now /requires/ sio0 to be present on the system. In `.../conf/files.i386' we have: i386/i386/i386-gdbstub.c optional ddb and `i386-gdbstub.c' calls many functions from the serial driver. This tripped me up since I have a kernel config without `sio*' (I don't have any serial devices!) but with DDB enabled. Is there anyway of having the kernel debugger present, without the serial devices being required? Perhaps we should separate `ddb' and `gdb-remote'? Koshy From owner-freebsd-current Sun Sep 1 22:40:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA13301 for current-outgoing; Sun, 1 Sep 1996 22:40:26 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA13295 for ; Sun, 1 Sep 1996 22:40:24 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.5/8.7.3) with SMTP id BAA04383; Mon, 2 Sep 1996 01:39:28 -0400 (EDT) Message-Id: <199609020539.BAA04383@whizzo.transsys.com> X-Authentication-Warning: whizzo.transsys.com: Host localhost.transsys.com [127.0.0.1] didn't use HELO protocol To: Michael Hancock cc: Kim Culhan , current@FreeBSD.org From: "Louis A. Mamakos" Subject: Re: Current build failure References: In-reply-to: Your message of "Mon, 02 Sep 1996 09:51:43 +0900." Date: Mon, 02 Sep 1996 01:39:27 -0400 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Keep supping and making (once a week or once a day), current is often not > buildable. Ah, I thought that while current was on the bleeding edge, the code should certainly at least compile before it's checked in! Hard to imagine any good reason why it wouldn't complile, short of problems in the build environment. Heck, I feel stupid for actually *testing* the code I contributed - I didn't realize broken code was OK too. > If you're new to current track it for at least a couple of months > doing all of the above before posting to current. Yeah, I've been tracking -current for more than a year, and little of this advice actually seemed to be helpful. But maybe it's just me. I also had problems getting a just checked-out version -current to get very far through 'make world'. louie From owner-freebsd-current Sun Sep 1 23:04:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA14261 for current-outgoing; Sun, 1 Sep 1996 23:04:19 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA14245 for ; Sun, 1 Sep 1996 23:04:14 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id GAA22349; Mon, 2 Sep 1996 06:02:42 GMT Date: Mon, 2 Sep 1996 15:02:41 +0900 (JST) From: Michael Hancock To: "Louis A. Mamakos" cc: Kim Culhan , current@FreeBSD.org Subject: Re: Current build failure In-Reply-To: <199609020539.BAA04383@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Sep 1996, Louis A. Mamakos wrote: > Heck, I feel stupid for actually *testing* the code I contributed - I > didn't realize broken code was OK too. Bad attitude. It's better to continue setting a good example. Add the following to the previous list of tips: If the author broke code because of carelessness send mail to the author and complain. Regards, Mike Hancock From owner-freebsd-current Sun Sep 1 23:17:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA14728 for current-outgoing; Sun, 1 Sep 1996 23:17:59 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA14723 for ; Sun, 1 Sep 1996 23:17:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id XAA03092; Sun, 1 Sep 1996 23:16:06 -0700 (PDT) Message-Id: <199609020616.XAA03092@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Louis A. Mamakos" cc: Michael Hancock , Kim Culhan , current@FreeBSD.org Subject: Re: Current build failure In-reply-to: Your message of "Mon, 02 Sep 1996 01:39:27 EDT." <199609020539.BAA04383@whizzo.transsys.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 01 Sep 1996 23:16:06 -0700 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> Keep supping and making (once a week or once a day), current is often not >> buildable. > >Ah, I thought that while current was on the bleeding edge, the code >should certainly at least compile before it's checked in! Hard to >imagine any good reason why it wouldn't complile, short of problems in >the build environment. > >Heck, I feel stupid for actually *testing* the code I contributed - I >didn't realize broken code was OK too. *Cough*...It's our policy for changes made in -current that they should not break the build system. Sometimes it's difficult to test all of the cases and bugs do slip in sometimes...but this is certainly not generally "ok". -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Sun Sep 1 23:20:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA14843 for current-outgoing; Sun, 1 Sep 1996 23:20:32 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA14825 for ; Sun, 1 Sep 1996 23:20:25 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id IAA14726; Mon, 2 Sep 1996 08:00:36 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.5/8.7.3) with SMTP id HAA19434; Mon, 2 Sep 1996 07:51:59 +0200 (MET DST) Date: Mon, 2 Sep 1996 07:51:59 +0200 (MET DST) From: Andreas Klemm To: John Polstra cc: current@freebsd.org Subject: Re: cvsup question, src/tools not updated, make release trouble In-Reply-To: <199609012239.PAA12163@austin.polstra.com> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 1 Sep 1996, John Polstra wrote: > > b) When getting cvs via cvsup I dont get the tools directory ... Why ? > > It's not a CVSup problem. It's because the mirror site you're using > hasn't updated his sup configuration files recently. The tools > directory was recently added to the "src-etc" collection on freefall. > But some of the other mirrors have not yet updated the necessary files > on their systems. > > I know which mirror you're using. I will contact the administrator > and ask him to fix it. Thanks ;) -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Sun Sep 1 23:23:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA14919 for current-outgoing; Sun, 1 Sep 1996 23:23:56 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA14914 for ; Sun, 1 Sep 1996 23:23:53 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id BAA08689; Mon, 2 Sep 1996 01:21:59 -0500 (EST) From: "John S. Dyson" Message-Id: <199609020621.BAA08689@dyson.iquest.net> Subject: Re: Current build failure To: louie@TransSys.COM (Louis A. Mamakos) Date: Mon, 2 Sep 1996 01:21:57 -0500 (EST) Cc: michaelh@cet.co.jp, kimc@w8hd.org, current@FreeBSD.org In-Reply-To: <199609020539.BAA04383@whizzo.transsys.com> from "Louis A. Mamakos" at Sep 2, 96 01:39:27 am Reply-To: dyson@FreeBSD.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > Keep supping and making (once a week or once a day), current is often not > > buildable. > > Ah, I thought that while current was on the bleeding edge, the code > should certainly at least compile before it's checked in! Hard to > imagine any good reason why it wouldn't complile, short of problems in > the build environment. > Actually, I think that the goal is to make sure that -current is buildable. However, it is on the "edge", and it is probably best not to condemn a developer for a mistake (or also likely, a tree that is internally inconsistant due to windows during the commit/download process.) It is exceptionally difficult to test some kinds of changes given limited resources (everything from subtile kernel changes to certain build environment changes.) Actually, since FreeBSD and it's ilk are volunteer efforts, we are fortunate that there are so many dedicated individuals spending their personal time on these projects!!! Not only that, but many of the developers don't have multiple machines to run carefully constructed tests. I believe that everyone on the project is trying to do the best job that they can, given their resources... But, again, I believe that it is pretty clear that we should be checking in code that each of us has tested as well as we can. Mess-ups do happen, and I am sure that each developer will correct the bugs they cause as quickly as possible. John From owner-freebsd-current Sun Sep 1 23:25:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA14978 for current-outgoing; Sun, 1 Sep 1996 23:25:21 -0700 (PDT) Received: from lear35.cytex.com (lear35.cytex.com [38.252.97.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA14973 for ; Sun, 1 Sep 1996 23:25:19 -0700 (PDT) Received: (from mbartley@localhost) by lear35.cytex.com (8.7.5/8.7.3) id XAA23842 for freebsd-current@freebsd.org; Sun, 1 Sep 1996 23:25:17 -0700 (PDT) From: Matt Bartley Message-Id: <199609020625.XAA23842@lear35.cytex.com> Subject: Re: Current build failure In-Reply-To: from Kim Culhan at "Sep 1, 96 09:19:23 pm" To: freebsd-current@freebsd.org Date: Sun, 1 Sep 1996 23:25:17 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Mon, 2 Sep 1996, Michael Hancock wrote: > > On Sun, 1 Sep 1996, Kim Culhan wrote: > > > /usr/src/usr.bin/locate/locate/locate.c:355: fastfind.c: No such file or > > > directory > > Check the obvious first. > [deleted] > > Does this mean noone else is having trouble building -current? It's happening to me too as of CTM level src-cur 2156. My code tree is up to level 2158, and the problem persists. Last successful make world was overnight on the night of August 30-31. From owner-freebsd-current Sun Sep 1 23:52:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA17040 for current-outgoing; Sun, 1 Sep 1996 23:52:41 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA17035 for ; Sun, 1 Sep 1996 23:52:35 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA29221; Mon, 2 Sep 1996 08:51:07 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA04468; Mon, 2 Sep 1996 08:51:06 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id IAA22016; Mon, 2 Sep 1996 08:31:48 +0200 (MET DST) From: J Wunsch Message-Id: <199609020631.IAA22016@uriah.heep.sax.de> Subject: Re: Anyone mind if I remove the following braindamage from test(1)? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 2 Sep 1996 08:31:48 +0200 (MET DST) Cc: bde@zeta.org.au (Bruce Evans), jkh@time.cdrom.com (Jordan K. Hubbard) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <13843.841630272@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 1, 96 07:11:12 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > root@time-> [ -d /tmp ] && echo Yup, its a directory > Yup, its a directory > root@time-> [ -d ] && echo Yup, its a directory > Yup, its a directory No: j@uriah 651% [ -d ] && echo Yup, -d aint empty. Yup, -d aint empty. That's apparently the reasoning behind. > Is there any POSIX weirdness which > mandates that test not do proper argument checking? The algorithm for determining the precedence of the operators and the 1 return value that shall be generated is based on the number of arguments 1 presented to test. (However, when using the [...] form, the right- 1 bracket final argument shall not be counted in this algorithm.) In the 1 following list, $1, $2, $3, and $4 represent the arguments presented to 1 test. 1 0 arguments: 1 Exit false (1). 1 1 argument: 1 Exit true (0) if $1 is not null; otherwise, exit false. 1 ... So unless this has been changed again in the standard (the above is from a draft), leave it as it is. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 1 23:53:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA17098 for current-outgoing; Sun, 1 Sep 1996 23:53:10 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA17088 for ; Sun, 1 Sep 1996 23:53:05 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA29228; Mon, 2 Sep 1996 08:51:09 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA04469; Mon, 2 Sep 1996 08:51:09 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id IAA22078; Mon, 2 Sep 1996 08:36:08 +0200 (MET DST) From: J Wunsch Message-Id: <199609020636.IAA22078@uriah.heep.sax.de> Subject: Re: Current build failure To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 2 Sep 1996 08:36:08 +0200 (MET DST) Cc: kimc@w8hd.org, dave@dogwood.com (Dave Cornejo) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199609020226.TAA17393@white.dogwood.com> from Dave Cornejo at "Sep 1, 96 07:26:11 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Dave Cornejo wrote: > I edited locate.c and replaced all occurances of > > #include > > with > > #include "fastfind.c" > > to get it to compile. Isn't this correct for files from the local directory? It bogusly hides another error. The build sequence should not rely on "" vs. <>, instead it must specify the right -I option. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 1 23:54:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA17210 for current-outgoing; Sun, 1 Sep 1996 23:54:42 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA17193 for ; Sun, 1 Sep 1996 23:54:31 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA29248; Mon, 2 Sep 1996 08:51:15 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA04477; Mon, 2 Sep 1996 08:51:14 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id IAA22126; Mon, 2 Sep 1996 08:39:56 +0200 (MET DST) From: J Wunsch Message-Id: <199609020639.IAA22126@uriah.heep.sax.de> Subject: Re: ddb now requires sio To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 2 Sep 1996 08:39:56 +0200 (MET DST) Cc: koshy@india.hp.com (A JOSEPH KOSHY) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199609020331.AA116635064@fakir.india.hp.com> from A JOSEPH KOSHY at "Sep 2, 96 08:31:04 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As A JOSEPH KOSHY wrote: > > `option DDB' now /requires/ sio0 to be present on the system. > > In `.../conf/files.i386' we have: > > i386/i386/i386-gdbstub.c optional ddb > > and `i386-gdbstub.c' calls many functions from the serial driver. This should be easy to circumvent by #include'ing "sio.h", and depending the gdb remote stuff from #if NSIO > 0. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Sep 2 00:04:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18183 for current-outgoing; Mon, 2 Sep 1996 00:04:35 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA18176 for ; Mon, 2 Sep 1996 00:04:32 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id AAA02895; Mon, 2 Sep 1996 00:03:46 -0700 (PDT) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users), bde@zeta.org.au (Bruce Evans) Subject: Re: Anyone mind if I remove the following braindamage from test(1)? In-reply-to: Your message of "Mon, 02 Sep 1996 08:31:48 +0200." <199609020631.IAA22016@uriah.heep.sax.de> Date: Mon, 02 Sep 1996 00:03:46 -0700 Message-ID: <2893.841647826@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > No: > > j@uriah 651% [ -d ] && echo Yup, -d aint empty. > Yup, -d aint empty. > > That's apparently the reasoning behind. > > > Is there any POSIX weirdness which > > mandates that test not do proper argument checking? > > The algorithm for determining the precedence of the operators and the 1 That's really weird, but at least -f, -e and so on are all broken in the same way. :-) And I still think it's a bug. I don't see why "[ -f /tmp/i_exist ]" and "[ -f ]" should be treated identically. I'd expect the opposite. Jordan From owner-freebsd-current Mon Sep 2 00:06:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18302 for current-outgoing; Mon, 2 Sep 1996 00:06:28 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA18297 for ; Mon, 2 Sep 1996 00:06:26 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id AAA02922; Mon, 2 Sep 1996 00:06:17 -0700 (PDT) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users), bde@zeta.org.au (Bruce Evans) Subject: Re: Anyone mind if I remove the following braindamage from test(1)? In-reply-to: Your message of "Mon, 02 Sep 1996 08:31:48 +0200." <199609020631.IAA22016@uriah.heep.sax.de> Date: Mon, 02 Sep 1996 00:06:17 -0700 Message-ID: <2920.841647977@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Also, > 1 argument: 1 > > Exit true (0) if $1 is not null; otherwise, exit false. 1 I'd expect that to hold true only if the argument was not a flag argument which required a parameter, then I'd expect it to puke. This would also help to quickly find instances where you'd undefined a necessary variable in the source tree, instead of giving a cryptic error message like: ``usage: rm [-f | -i] [-dPRr] file ...'' Jordan From owner-freebsd-current Mon Sep 2 00:22:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA19171 for current-outgoing; Mon, 2 Sep 1996 00:22:27 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA19165 for ; Mon, 2 Sep 1996 00:22:23 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA29949; Mon, 2 Sep 1996 09:21:15 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA04854; Mon, 2 Sep 1996 09:21:15 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA22323; Mon, 2 Sep 1996 09:10:14 +0200 (MET DST) From: J Wunsch Message-Id: <199609020710.JAA22323@uriah.heep.sax.de> Subject: Re: Current build failure To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 2 Sep 1996 09:10:13 +0200 (MET DST) Cc: louie@TransSys.COM (Louis A. Mamakos) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199609020539.BAA04383@whizzo.transsys.com> from "Louis A. Mamakos" at "Sep 2, 96 01:39:27 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Louis A. Mamakos wrote: > > Keep supping and making (once a week or once a day), current is often not > > buildable. > > Ah, I thought that while current was on the bleeding edge, the code > should certainly at least compile before it's checked in! Hard to > imagine any good reason why it wouldn't complile, short of problems in > the build environment. Committers are humans only. To err is human. If you had looked at the log for this problem, you would have known that it *was* buildable for the person who's committed it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Sep 2 00:54:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA20506 for current-outgoing; Mon, 2 Sep 1996 00:54:01 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA20497 for ; Mon, 2 Sep 1996 00:53:11 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA00828; Mon, 2 Sep 1996 09:51:22 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA05165; Mon, 2 Sep 1996 09:51:21 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA22529; Mon, 2 Sep 1996 09:47:52 +0200 (MET DST) From: J Wunsch Message-Id: <199609020747.JAA22529@uriah.heep.sax.de> Subject: Re: Anyone mind if I remove the following braindamage from test(1)? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 2 Sep 1996 09:47:52 +0200 (MET DST) Cc: jkh@time.cdrom.com (Jordan K. Hubbard), bde@zeta.org.au (Bruce Evans) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <2893.841647826@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 2, 96 00:03:46 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > And I still think it's a bug. I don't see why "[ -f /tmp/i_exist ]" > and "[ -f ]" should be treated identically. I'd expect the opposite. It's not a bug, it's a weird feature. Any single argument is considered to be the test for a string. No such thing like ``option flag'' for a single argument. Thus: read foobar if [ "$foobar" ] then : else echo You fool! You haven't entered anything! exit 1 fi ...works. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Sep 2 01:28:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA24405 for current-outgoing; Mon, 2 Sep 1996 01:28:24 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA24252 for ; Mon, 2 Sep 1996 01:27:33 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA10477; Mon, 2 Sep 1996 18:24:59 +1000 Date: Mon, 2 Sep 1996 18:24:59 +1000 From: Bruce Evans Message-Id: <199609020824.SAA10477@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: ddb now requires sio Cc: koshy@india.hp.com Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As A JOSEPH KOSHY wrote: > > `option DDB' now /requires/ sio0 to be present on the system. > > In `.../conf/files.i386' we have: > > i386/i386/i386-gdbstub.c optional ddb > > and `i386-gdbstub.c' calls many functions from the serial driver. This should be easy to circumvent by #include'ing "sio.h", and depending the gdb remote stuff from #if NSIO > 0. i386-gdbstub.c should call cngetc() instead of siocngetc(), etc. This probably doesn't work now because the console driver is so primitive: 1) it does LF -> CRLF translations on output, and there is no way to stop this. 2) It only supports _one_ console device and that device can't be changed properly after it is decided at boot time. This is OK for /dev/console but it leaves the driver `cn' functions for all devices other than the console inaccessible, and for debugging it's best if the physical device is different from the one used for the console. The low level (driver) `cn' functions take a dev_t arg but all drivers ignore it, while the high level `cn' functions don't take a dev_t arg. Bruce From owner-freebsd-current Mon Sep 2 04:02:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05425 for current-outgoing; Mon, 2 Sep 1996 04:02:16 -0700 (PDT) Received: from kanto.cc.jyu.fi (root@kanto.cc.jyu.fi [130.234.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA05419; Mon, 2 Sep 1996 04:02:12 -0700 (PDT) Received: from localhost (kallio@localhost [127.0.0.1]) by kanto.cc.jyu.fi (8.7.2/8.7.2) with SMTP id OAA19458; Mon, 2 Sep 1996 14:01:56 +0300 (EET DST) Date: Mon, 2 Sep 1996 14:01:55 +0300 (EET DST) From: Seppo Kallio To: current@FreeBSD.ORG cc: users@FreeBSD.ORG Subject: Format of FreeBSD 2.2-current cdrom In-Reply-To: <26457.835279742@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I want to make my own special FreeBSD CD ROM. Can some one tell me how should the directory tree look to get for ex. 2.2-960801-SNAP boot floppy to work and install from my own CD ROM. Does it start /dists/2.2-960801-SNAP/ and then continue as in ftp archives, that is something like: HARDWARE.TXT RELNOTES.TXT compat20/ info/ src/ INSTALL.TXT XF86312@ des/ manpages/ xperimnt/ MIRROR.SITES bin/ dict/ packages@ README.TXT commerce/ floppies/ ports@ READNOW.TXT compat1x/ games/ proflibs/ (This is actually from 2.1R) Seppo Kallio kallio@jyu.fi Computing Center Fax +358-14-603611 From owner-freebsd-current Mon Sep 2 05:35:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA09006 for current-outgoing; Mon, 2 Sep 1996 05:35:43 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA08998 for ; Mon, 2 Sep 1996 05:35:40 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.5/8.7.3) with SMTP id IAA11042; Mon, 2 Sep 1996 08:34:33 -0400 (EDT) Message-Id: <199609021234.IAA11042@whizzo.transsys.com> X-Authentication-Warning: whizzo.transsys.com: Host localhost.transsys.com [127.0.0.1] didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) From: "Louis A. Mamakos" Subject: Re: Current build failure References: <199609020710.JAA22323@uriah.heep.sax.de> In-reply-to: Your message of "Mon, 02 Sep 1996 09:10:13 +0200." <199609020710.JAA22323@uriah.heep.sax.de> Date: Mon, 02 Sep 1996 08:34:32 -0400 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Keep supping and making (once a week or once a day), current is often not > > > buildable. > > > > Ah, I thought that while current was on the bleeding edge, the code > > should certainly at least compile before it's checked in! Hard to > > imagine any good reason why it wouldn't complile, short of problems in > > the build environment. > > Committers are humans only. To err is human. > > If you had looked at the log for this problem, you would have known > that it *was* buildable for the person who's committed it. Sorry if my bit of sarcasm was not obvious. I was simply upset that in response to a perfectly reasonable query by someone to the list regarding their failure to get -current to build, yielded a list of mostly unhelpful suggestions by someone else. I simply objected to "explaining away" the problem with the excuse that "you shouldn't expect current to always build". I'm sure that people will always make mistakes, and that's fine, but implication was a bit different than that. louie From owner-freebsd-current Mon Sep 2 06:46:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA12028 for current-outgoing; Mon, 2 Sep 1996 06:46:58 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA12022 for ; Mon, 2 Sep 1996 06:46:56 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA12940; Mon, 2 Sep 1996 09:46:00 -0400 Date: Mon, 2 Sep 1996 09:46:00 -0400 From: Garrett Wollman Message-Id: <9609021346.AA12940@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users), bde@zeta.org.au (Bruce Evans) Subject: Re: Anyone mind if I remove the following braindamage from test(1)? In-Reply-To: <2920.841647977@time.cdrom.com> References: <199609020631.IAA22016@uriah.heep.sax.de> <2920.841647977@time.cdrom.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk < said: > I'd expect that to hold true only if the argument was not a flag > argument which required a parameter, then I'd expect it to puke. This > would also help to quickly find instances where you'd undefined a > necessary variable in the source tree, instead of giving a cryptic > error message like: ``usage: rm [-f | -i] [-dPRr] file ...'' Use: [ -d "$foo" ] instead of [ -d $foo ] . This will ensure that two arguments get passed to the `-d' primitive, even if $foo is not defined. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Mon Sep 2 07:00:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA13105 for current-outgoing; Mon, 2 Sep 1996 07:00:42 -0700 (PDT) Received: from nol.net (root@dazed.nol.net [206.126.32.101]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA13093; Mon, 2 Sep 1996 07:00:39 -0700 (PDT) Received: from dazed.nol.net (blh@dazed.nol.net [206.126.32.101]) by nol.net (8.7.5/NOL - 8.*) with SMTP id JAA01925; Mon, 2 Sep 1996 09:00:36 -0500 (CDT) X-AUTH: NOLNET SENDMAIL AUTH Date: Mon, 2 Sep 1996 09:00:34 -0500 (CDT) From: "Brett L. Hawn" To: freebsd-questions@freebsd.org cc: freebsd-current@freebsd.org Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe [-] Brett L. Hawn (blh@nol.net) [-] [-] Networks On-Line - Houston, Texas [-] [-] 713-467-7100 [-] From owner-freebsd-current Mon Sep 2 09:34:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA26506 for current-outgoing; Mon, 2 Sep 1996 09:34:27 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA26501 for ; Mon, 2 Sep 1996 09:34:25 -0700 (PDT) Received: from skipper.eng.umd.edu (skipper.eng.umd.edu [129.2.103.24]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id MAA04823 for ; Mon, 2 Sep 1996 12:34:22 -0400 (EDT) Received: from localhost (chuckr@localhost) by skipper.eng.umd.edu (8.7.5/8.7.3) with SMTP id MAA16235 for ; Mon, 2 Sep 1996 12:34:21 -0400 (EDT) X-Authentication-Warning: skipper.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 2 Sep 1996 12:34:21 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@skipper.eng.umd.edu To: FreeBSD current Subject: ppp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am trying to bring my ppp back, after not using it for several months, or maybe longer. I can see that a lot of stuff ahs improved (at least under current). I have the standard setup recommended in the ppp man page, and illustrated in the ppp.conf and ppp.linkup files, and I can bring up ppp, and the new route is inserted nicely into the routing table, and it even goes so far as to delete it when it's done. The only thing it isn't doing is making that new route default, so nothing on my machine addresses it. Anyone know what I'm doing wrong? I'm NOT running routed, I've seen all the discussion on that. The only reason I didn't post this to -questions is because I don't want to get a lot of answers involved with 2.1.5 versions. If I was wrong in this, Ill try there. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Sep 2 10:13:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01208 for current-outgoing; Mon, 2 Sep 1996 10:13:26 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA01201 for ; Mon, 2 Sep 1996 10:13:24 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id KAA04349; Mon, 2 Sep 1996 10:13:14 -0700 (PDT) Message-Id: <199609021713.KAA04349@austin.polstra.com> To: Andreas Klemm cc: current@freebsd.org Subject: Re: cvsup question, src/tools not updated, make release trouble In-reply-to: Your message of "Mon, 02 Sep 1996 07:51:59 +0200." Date: Mon, 02 Sep 1996 10:13:14 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I know which mirror you're using. I will contact the administrator > > and ask him to fix it. > > Thanks ;) You're welcome. It's fixed now. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Mon Sep 2 10:26:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03166 for current-outgoing; Mon, 2 Sep 1996 10:26:40 -0700 (PDT) Received: from lear35.cytex.com (lear35.cytex.com [38.252.97.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA03157 for ; Mon, 2 Sep 1996 10:26:37 -0700 (PDT) Received: (from mbartley@localhost) by lear35.cytex.com (8.7.5/8.7.3) id KAA05664 for freebsd-current@freebsd.org; Mon, 2 Sep 1996 10:26:36 -0700 (PDT) From: Matt Bartley Message-Id: <199609021726.KAA05664@lear35.cytex.com> Subject: Re: Current build failure In-Reply-To: <199609020625.XAA23842@lear35.cytex.com> from Matt Bartley at "Sep 1, 96 11:25:17 pm" To: freebsd-current@freebsd.org Date: Mon, 2 Sep 1996 10:26:35 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> /usr/src/usr.bin/locate/locate/locate.c:355: fastfind.c: No such file or >>>> directory > It's happening to me too as of CTM level src-cur 2156. My code tree > is up to level 2158, and the problem persists. Last successful make > world was overnight on the night of August 30-31. Fixed by src-cur 2159. From owner-freebsd-current Mon Sep 2 11:29:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA05310 for current-outgoing; Mon, 2 Sep 1996 11:29:25 -0700 (PDT) Received: from moonpie.w8hd.org (moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA05305 for ; Mon, 2 Sep 1996 11:29:23 -0700 (PDT) Received: from localhost (kimc@localhost) by moonpie.w8hd.org (8.7.5/8.6.12) with SMTP id OAA02168 for ; Mon, 2 Sep 1996 14:29:21 -0400 (EDT) X-Authentication-Warning: moonpie.w8hd.org: kimc owned process doing -bs Date: Mon, 2 Sep 1996 14:29:21 -0400 (EDT) From: Kim Culhan To: current@FreeBSD.org Subject: Latest Current build failure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Now this just in: cc -O -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -DHAVE_CONFIG_H -c/usr/src/gnu/usr.bin/cvs/cvs/release.c /usr/src/gnu/usr.bin/cvs/cvs/release.c: In function `release_delete': /usr/src/gnu/usr.bin/cvs/cvs/release.c:254: `RM' undeclared (first use this function) /usr/src/gnu/usr.bin/cvs/cvs/release.c:254: (Each undeclared identifier is reported only once /usr/src/gnu/usr.bin/cvs/cvs/release.c:254: for each function it appears in.) *** Error code 1 Stop. regards kim -- kimc@w8hd.org From owner-freebsd-current Mon Sep 2 12:31:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08387 for current-outgoing; Mon, 2 Sep 1996 12:31:58 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA08382 for ; Mon, 2 Sep 1996 12:31:55 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA32641; Tue, 3 Sep 1996 05:30:00 +1000 Date: Tue, 3 Sep 1996 05:30:00 +1000 From: Bruce Evans Message-Id: <199609021930.FAA32641@godzilla.zeta.org.au> To: jkh@time.cdrom.com, wollman@lcs.mit.edu Subject: Re: Anyone mind if I remove the following braindamage from test(1)? Cc: bde@zeta.org.au, freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Use: > [ -d "$foo" ] >instead of > [ -d $foo ] >. This will ensure that two arguments get passed to the `-d' >primitive, even if $foo is not defined. This only works right on POSIX systems. Under FreeBSD, "" is an alias for ".", so if $foo is empty, [ -d "$foo" ] almost always succeeds. There is also a bug in bash's builtin test. On freefall: $bash test -d ''; echo $? 1 $bash /bin/test -d ''; echo $? 0 I have used this fix for a year or three. I fixed empty pathnames in many programs but there are still several standard programs with harmless bugs in this area. Tar apparently strips one too many slash from "/", and there's a rare case in gzip where it does a harmless stat() of "". Bruce diff -c2 src/sys/kern/vfs_lookup.c~ src/sys/kern/vfs_lookup.c *** src/sys/kern/vfs_lookup.c~ Thu Jan 4 17:07:54 1996 --- src/sys/kern/vfs_lookup.c Wed Mar 6 17:58:20 1996 *************** *** 53,56 **** --- 53,57 ---- #include #include + #include #ifdef KTRACE *************** *** 113,116 **** --- 114,129 ---- error = copyinstr(ndp->ni_dirp, cnp->cn_pnbuf, MAXPATHLEN, (u_int *)&ndp->ni_pathlen); + + /* + * Don't allow empty pathname. + * Log the error until we find the standard utilities that cause it. + */ + if (!error && *cnp->cn_pnbuf == '\0') { + log(LOG_ERR, + "pid %d (%s) called namei with an empty pathname\n", + cnp->cn_proc->p_pid, cnp->cn_proc->p_comm); + error = ENOENT; + } + if (error) { free(cnp->cn_pnbuf, M_NAMEI); From owner-freebsd-current Mon Sep 2 14:11:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13118 for current-outgoing; Mon, 2 Sep 1996 14:11:40 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA13112 for ; Mon, 2 Sep 1996 14:11:35 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03052; Mon, 2 Sep 1996 14:09:51 -0700 From: Terry Lambert Message-Id: <199609022109.OAA03052@phaeton.artisoft.com> Subject: Re: Anyone mind if I remove the following braindamage from test(1)? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 2 Sep 1996 14:09:50 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org, bde@zeta.org.au In-Reply-To: <2920.841647977@time.cdrom.com> from "Jordan K. Hubbard" at Sep 2, 96 00:06:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I'd expect that to hold true only if the argument was not a flag > argument which required a parameter, then I'd expect it to puke. This > would also help to quickly find instances where you'd undefined a > necessary variable in the source tree, instead of giving a cryptic > error message like: ``usage: rm [-f | -i] [-dPRr] file ...'' I agree; a flag isn't an argument, it's a flag. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 2 14:28:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13790 for current-outgoing; Mon, 2 Sep 1996 14:28:17 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA13783 for ; Mon, 2 Sep 1996 14:28:11 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03091; Mon, 2 Sep 1996 14:26:51 -0700 From: Terry Lambert Message-Id: <199609022126.OAA03091@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: kimc@w8hd.org (Kim Culhan) Date: Mon, 2 Sep 1996 14:26:51 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: from "Kim Culhan" at Sep 2, 96 02:29:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Now this just in: > > cc -O -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib > -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src > -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -DHAVE_CONFIG_H > -c/usr/src/gnu/usr.bin/cvs/cvs/release.c > /usr/src/gnu/usr.bin/cvs/cvs/release.c: In function `release_delete': > /usr/src/gnu/usr.bin/cvs/cvs/release.c:254: `RM' undeclared (first use > this function) > /usr/src/gnu/usr.bin/cvs/cvs/release.c:254: (Each undeclared identifier is > reported only once > /usr/src/gnu/usr.bin/cvs/cvs/release.c:254: for each function it appears > in.) > *** Error code 1 > > Stop. --------------------------------------------------------------------------- "Triumph of the Nerds: Volume VII -- How FreeBSD beat Microsoft" Copyright (c) 2011 Robert Cringely ... Cringely: You said there was an event in 1996 that "galvanized the core team into action", what exactly did you mean? Hubbard: Well, you know, made them sit up and take note of their professional standards. Cringley: ...And that event was? Hubbard: Well, it was when Kim Culhan actually made us realize that people were out there *compiling* the thing themselves; I mean, that was really astonishing... but the *really* astonishing thing was that Kim was expecting the thing to *work*, as if the source tree itself was an "out of the box" product. Cringely: What did Terry say about that? Hubbard: Well, you've heard all about Terry; he did what you'd expect Terry to do; he wrote a three page article on "implied contracts in putting up source trees for public download"... Cringely: ... I suppose that's the sort of thing that got him called "the Ralph Nader of Software"... Hubbard: No, no that came later after the Netscape/Microsoft merger, just before they finally pushed S-Patent's through congress... ... --------------------------------------------------------------------------- Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 2 14:52:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14628 for current-outgoing; Mon, 2 Sep 1996 14:52:26 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA14622 for ; Mon, 2 Sep 1996 14:52:22 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id OAA05780; Mon, 2 Sep 1996 14:52:09 -0700 (PDT) To: Garrett Wollman cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users), bde@zeta.org.au (Bruce Evans) Subject: Re: Anyone mind if I remove the following braindamage from test(1)? In-reply-to: Your message of "Mon, 02 Sep 1996 09:46:00 EDT." <9609021346.AA12940@halloran-eldar.lcs.mit.edu> Date: Mon, 02 Sep 1996 14:52:09 -0700 Message-ID: <5777.841701129@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Use: > [ -d "$foo" ] > instead of > [ -d $foo ] Hey, no fair using your brain! :-) That sounds like a good compromise. Jordan From owner-freebsd-current Mon Sep 2 16:10:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA18264 for current-outgoing; Mon, 2 Sep 1996 16:10:22 -0700 (PDT) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA18258 for ; Mon, 2 Sep 1996 16:10:19 -0700 (PDT) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.7.5/8.6.12) with ESMTP id QAA10870; Mon, 2 Sep 1996 16:08:24 -0700 (PDT) Message-Id: <199609022308.QAA10870@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: Terry Lambert cc: jkh@time.cdrom.com (Jordan K. Hubbard), joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org, bde@zeta.org.au Subject: Re: Anyone mind if I remove the following braindamage from test(1)? Date: Mon, 02 Sep 1996 16:08:24 -0700 From: "David E. Tweten" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Initially quoting someone else, terry@lambert.org said: >> I'd expect that to hold true only if the argument was not a flag >>argument which required a parameter, then I'd expect it to puke. >I agree; a flag isn't an argument, it's a flag. Ah, but POSIX test doesn't have flags. It has "operators" ("=", "!=", "-gt", and the like) and "elements of primaries". A primary is something like "-d file" (my quotes), which in this case contains two "elements". POSIX goes on to say that "string" (my quotes) is a primary that is true if the string is non-null. And, "All operators and elements of primaries shall be presented as separate arguments to the test utility." As has previously been quoted in this thread, it continues by saying that test with a single "argument" returns true (0) if that argument is non-null, and returns false (1) otherwise, obviously treating it as the "string" primary. So I guess under POSIX test, everything is an argument and [ -d ] is in fact a test to see of "-d" is the null string. -- David E. Tweten | 2047-bit PGP Key fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. From owner-freebsd-current Mon Sep 2 16:27:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA18778 for current-outgoing; Mon, 2 Sep 1996 16:27:20 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA18773 for ; Mon, 2 Sep 1996 16:27:18 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id QAA06363; Mon, 2 Sep 1996 16:26:25 -0700 (PDT) To: Terry Lambert cc: kimc@w8hd.org (Kim Culhan), current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Mon, 02 Sep 1996 14:26:51 PDT." <199609022126.OAA03091@phaeton.artisoft.com> Date: Mon, 02 Sep 1996 16:26:25 -0700 Message-ID: <6361.841706785@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk King: "This week. On Larry King live. Jordan Hubbard. On my show. And also. The answer. To the question. Of why I talk in short sound-bites. Like Howard Cosell. That irritating git. Who's now dead. Unlike my show. Which is Live!" [fade to 2nd video feed and roll 15 solid minutes commercials, 12 from the national feed and 3 more from the local affiliate which feature ``Ingnacio "Bud" Schwartz'' sitting astride a steer and trying to sell used cars - he is unsuccessful on both counts] King: "And we're back! Here with Jordan Hubbard. Of the FreeBSD Project. Mr. Hubbard, welcome to the show." Hubbard: "Thank you Larry, and may I say that you look absolutely smashing in those suspenders. You're no Lou Grant, but you're clearly capable of playing him on T.V." King: "Thank you. You're very kind. Moving on to our first question. What is your opinion of Cringeley's new Book, "How FreeBSD beat Microsoft." Would you say it's accurate?" Hubbard: "No, Larry, it's really not. First off, Cringely refers to a period in 1996 when he claims that our sources were broken and that this galvanized us into some sort of action. The event in question never actually took place, and it was really just one of our users with a broken source tree all along. King: "That's facinating. I'm afraid we have to take a commercial break." Commercial: "Hi, I'm Bud, and I'd like to sell you a car! Aieeeeeeeee!!!" [pandemonium ensues as Ignacio Schwartz tumbles from his steer and various people rush in from off-camera as it does his best to trample him into jelly. Several bystanders can be seen cheering in the background] King: ".. and then Elvis says to me, "Larry, I have never seen someone eat as many donuts as that in one sitting. I deeply respect you." And I said, "Elvis, I'm not worthy to... Oh, we're back! I'm Larry King, and I'm sitting here with Jordan Hubbard, who's refuting the facts stated in Cringeley's new book ``How FreeBSD beat Microsoft.'' You were just referring to Terry Lambert, also mentioned in the book, and how he got the title "the O.J. Simpson of Software." Hubbard: "Ah, that's very interesting. Yes, that came after a highly publicised case involving Terry and industrial espionage that ..." King: "Whoops! I'm afraid that's all we have time for! This has been Larry King. Reporting live, from ..." *click* Jordan From owner-freebsd-current Mon Sep 2 16:37:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA19128 for current-outgoing; Mon, 2 Sep 1996 16:37:36 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA19123 for ; Mon, 2 Sep 1996 16:37:35 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA19861; Mon, 2 Sep 1996 16:36:15 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) by whistle.com via smap (V1.3) id sma019857; Mon Sep 2 16:35:48 1996 Date: Mon, 2 Sep 1996 16:34:38 -0700 (PDT) From: Julian Elischer To: Bruce Evans cc: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de, koshy@india.hp.com Subject: Re: ddb now requires sio In-Reply-To: <199609020824.SAA10477@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Sep 1996, Bruce Evans wrote: > i386-gdbstub.c should call cngetc() instead of siocngetc(), etc. > This probably doesn't work now because the console driver is so > primitive: no I use the gdb on sio0 while having the console on the keyboard.. So I wouldn't want that .. I mean,, what possible use would gdb-stub be on a vga/keyboard? > From owner-freebsd-current Mon Sep 2 17:23:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA20896 for current-outgoing; Mon, 2 Sep 1996 17:23:34 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA20891 for ; Mon, 2 Sep 1996 17:23:29 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id KAA09617; Tue, 3 Sep 1996 10:19:07 +1000 Date: Tue, 3 Sep 1996 10:19:07 +1000 From: Bruce Evans Message-Id: <199609030019.KAA09617@godzilla.zeta.org.au> To: bde@zeta.org.au, julian@current1.whistle.com Subject: Re: ddb now requires sio Cc: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de, koshy@india.hp.com Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> i386-gdbstub.c should call cngetc() instead of siocngetc(), etc. >> This probably doesn't work now because the console driver is so >> primitive: >no I use the gdb on sio0 while having the console on the keyboard.. >So I wouldn't want that .. >I mean,, >what possible use would gdb-stub be on a vga/keyboard? None. But if the console is on sio0 you'd better not put gdb on sio0. You might want to put it on cy7. It's a long way from siocngetc(0) to cy7. Bruce From owner-freebsd-current Mon Sep 2 17:31:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA21117 for current-outgoing; Mon, 2 Sep 1996 17:31:42 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA21112 for ; Mon, 2 Sep 1996 17:31:38 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA28762; Tue, 3 Sep 1996 00:31:13 GMT Date: Tue, 3 Sep 1996 09:31:13 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: Kim Culhan , current@FreeBSD.org Subject: Re: Latest Current build failure In-Reply-To: <199609022126.OAA03091@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I haven't seen any real solutions to the buildable-current problem. Just to make it easy I'll describe 4 scenerios that break current. Note the order doesn't necessarily imply frequency of occurences. 1) Programmer commits code that wasn't tested well enough. 2) A change is made to a global resource such as a header file or a compile flag that breaks other programmer's code. 3) Operator error on the part of the (cv)sup user. 4) Corrupt CVS tree. REMEDIES 1) Buildable-current meister (Louie, Terry, or whoever volunteers) sends constructive criticism to programmer to shape up. Others will probably do the same, I will. 2) Assign global impact determination and resolution function to Buildable-current meister. CVS does not have the functionality to support this automatically, so additional tools are required. Perhaps the Buildable-current meister has UnixWare or Solaris and can mount to a FreeBSD box containing the Buildable sources and run cscope to determine the impact of the header file change. A Perl script is another solution. The Buildable-current meister has a programmer database and uses a custom script to automagically send mail to all programmers that the change will impact using the output of cscope or equivalent tool. The Buildable-current meister patiently collects all changes and does a make world and if make world is successful the tree is made available for public access. 3) Documentation. freebsd-current@freebsd.org cvs-all@freebsd.org. 4) Someone volunteers to write a utility that checks the integrity of the CVS repository. Does anyone else have any better ideas? I can think of other ways to do 2), but they all involve the assignment of a single Buildable-current meister. Regards, Mike Hancock From owner-freebsd-current Mon Sep 2 19:37:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA25443 for current-outgoing; Mon, 2 Sep 1996 19:37:23 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA25437 for ; Mon, 2 Sep 1996 19:37:20 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id TAA06667; Mon, 2 Sep 1996 19:36:11 -0700 (PDT) To: Michael Hancock cc: Terry Lambert , Kim Culhan , current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Tue, 03 Sep 1996 09:31:13 +0900." Date: Mon, 02 Sep 1996 19:36:11 -0700 Message-ID: <6665.841718171@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I haven't seen any real solutions to the buildable-current problem. Actually, I've been proposing a solution for close to 2 years now, we've just never actually set about the process of implementing it. 1. What is currently thought of as -current right now goes into "slow update mode", the tree no longer being updated automatically via cron, as it is now. 2. Those -current users who are really developers and don't mind temporary brokenness (they perhaps even being occasionally responsible for same) either CVSup the CVS tree or the `.' tag from it. Grabbing the `.' (or HEAD) tag with CVSup is also therefore no longer considered as synonymous with "supping -current" 3. The "slow update" of the -current tree on freefall, from which the sup and CTM services are provided, is driven by a "cookie collector" process - some PERL script hanging off an email alias which collects success-or-fail messages from a set of designated build boxes. Each designated build box, some of which we could provide here at WC, commits to updating to and building the CVS HEAD branch once every 24 hours, emitting an email at the end to know the central cookie collector know the exit status of the build. If a majority of the build boxes report success during a given 24 hour period, and I'd recommend making it a majority vote since a given percentage will *always* be hosed due to local stupidity of some sort, then the for-public-consumption tree will be updated. That would solve the problem nicely, but so far none of the "current is broken *again*!" complainers have been willing to sit down and actually implement the framework necessary for making this work. Jordan P.S. A human-driven model for this will *NOT* work. Such a buildmeister person will simply burn out on the process in short order, needlessly wasting everyone's time and one buildmeister. From owner-freebsd-current Mon Sep 2 19:50:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA26425 for current-outgoing; Mon, 2 Sep 1996 19:50:22 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA26413 for ; Mon, 2 Sep 1996 19:50:18 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id TAA06745; Mon, 2 Sep 1996 19:48:40 -0700 (PDT) cc: Michael Hancock , Terry Lambert , Kim Culhan , current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Mon, 02 Sep 1996 19:36:11 PDT." <6665.841718171@time.cdrom.com> Date: Mon, 02 Sep 1996 19:48:40 -0700 Message-ID: <6742.841718920@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 24 hours, emitting an email at the end to know the central cookie ^^^^let > collector know the exit status of the build. If a majority of the Boy, I've gotta start checking my email more closely for typos... Fast is nice, but that's too fast! :-) Jordan From owner-freebsd-current Mon Sep 2 20:11:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA27832 for current-outgoing; Mon, 2 Sep 1996 20:11:59 -0700 (PDT) Received: from mickey.umiacs.umd.edu (mickey.umiacs.umd.edu [128.8.120.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA27825 for ; Mon, 2 Sep 1996 20:11:56 -0700 (PDT) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.5/UMIACS-0.9/04-05-88) id XAA04539; Mon, 2 Sep 1996 23:11:38 -0400 (EDT) Date: Mon, 2 Sep 1996 23:11:38 -0400 (EDT) From: Sujal Patel To: "Jordan K. Hubbard" cc: current@FreeBSD.org Subject: Re: Latest Current build failure In-Reply-To: <6665.841718171@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Sep 1996, Jordan K. Hubbard wrote: > > I haven't seen any real solutions to the buildable-current problem. > > Actually, I've been proposing a solution for close to 2 years now, > we've just never actually set about the process of implementing it. Perhaps it's just me, but I really don't expect current to build all the time. It's just a fact of life... That's why it's called -current. If you really need something that's in -current, then just wait for the 2.2 SNAPS, they are fairly regular. Sujal From owner-freebsd-current Mon Sep 2 20:13:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA27923 for current-outgoing; Mon, 2 Sep 1996 20:13:20 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA27918 for ; Mon, 2 Sep 1996 20:13:17 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id WAA06268; Mon, 2 Sep 1996 22:11:47 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Sep 1996 22:11:48 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If a majority of the > build boxes report success during a given 24 hour period, and I'd > recommend making it a majority vote since a given percentage will > *always* be hosed due to local stupidity of some sort, then the > for-public-consumption tree will be updated. > >That would solve the problem nicely, but so far none of the "current >is broken *again*!" complainers have been willing to sit down and >actually implement the framework necessary for making this work. The only potential problem that I see has to do with the problem of builds which depend on previous builds. If I have ctm release 100, and it works, I would verfify that 101 is OK. >From 101, I might verify 102, etc. However, 102 might NOT build from 100 because it depends on the installation of something in 101. :-( >P.S. A human-driven model for this will *NOT* work. Such a >buildmeister person will simply burn out on the process in short >order, needlessly wasting everyone's time and one buildmeister. On this, I agree. From owner-freebsd-current Mon Sep 2 20:47:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA29218 for current-outgoing; Mon, 2 Sep 1996 20:47:53 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA29211 for ; Mon, 2 Sep 1996 20:47:46 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id UAA06864; Mon, 2 Sep 1996 20:47:41 -0700 (PDT) To: rkw@dataplex.net (Richard Wackerbarth) cc: current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Mon, 02 Sep 1996 22:11:48 CDT." Date: Mon, 02 Sep 1996 20:47:40 -0700 Message-ID: <6861.841722460@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If I have ctm release 100, and it works, I would verfify that 101 is OK. > From 101, I might verify 102, etc. > > However, 102 might NOT build from 100 because it depends on the > installation of something in 101. :-( Then the thing that was depended on should have been added to the bootstrap target between 101 and 102, as is our general policy. We'd probably also have to get a little more anal about insisting that folks try the bootstrap target before crying wolf, but it should (in theory, of course) work. Jordan From owner-freebsd-current Mon Sep 2 20:57:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA29610 for current-outgoing; Mon, 2 Sep 1996 20:57:14 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA29604 for ; Mon, 2 Sep 1996 20:57:09 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id UAA06886; Mon, 2 Sep 1996 20:57:04 -0700 (PDT) To: Sujal Patel cc: current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Mon, 02 Sep 1996 23:11:38 EDT." Date: Mon, 02 Sep 1996 20:57:04 -0700 Message-ID: <6884.841723024@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Perhaps it's just me, but I really don't expect current to build all the > time. It's just a fact of life... That's why it's called -current. Well, while I'd be the first to agree with you, it still appears to be the case that a goodly percentage of folks want, for lack of a better and less oxymoronic term, a "stable-current." I also think that we can give them this and without sacrificing developer access to the "real" -current (HEAD). What would help would be a concerted effort on the part of the -current developers to move over to CVSup or CTM'd, grabbing the CVS tree in cases where the latter is used. I also know that people have traditionally complained that a CVS tree takes up lots of space, but c'mon guys - disk space is disgustingly cheap now. I think we can stop citing that as a blocking factor, just as we stopped letting 4Mb machines or 256K VGA cards stand in the way of previous development. Let's get all the developers moved over to the proper services they need for doing their jobs, then we can take CTM-current and sup-current and reshape them for the needs of those who like to stay up to date but not *that* up to date. Just judging by the amount of push-back I've received over the years, I think that group of folks is larger (and louder) than you think. It's probably time we sorted them out, if for no other reason than to eliminate the 47 copies of "-current is broken again!" messages we currently get on -current (or -hackers, or both) whenever something breaks. :-) Jordan From owner-freebsd-current Mon Sep 2 23:19:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA07799 for current-outgoing; Mon, 2 Sep 1996 23:19:24 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA07794 for ; Mon, 2 Sep 1996 23:19:22 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id BAA08836; Tue, 3 Sep 1996 01:19:17 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 01:19:17 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Perhaps it's just me, but I really don't expect current to build all the >> time. It's just a fact of life... That's why it's called -current. > >Well, while I'd be the first to agree with you, it still appears to be >the case that a goodly percentage of folks want, for lack of a better >and less oxymoronic term, a "stable-current." I also think that we can >give them this and without sacrificing developer access to the "real" >-current (HEAD). > >What would help would be a concerted effort on the part of the >-current developers to move over to CVSup or CTM'd, grabbing the CVS >tree in cases where the latter is used. I also know that people have >traditionally complained that a CVS tree takes up lots of space, but >c'mon guys - disk space is disgustingly cheap now. I think we can >stop citing that as a blocking factor, just as we stopped letting 4Mb >machines or 256K VGA cards stand in the way of previous development. >Let's get all the developers moved over to the proper services they >need for doing their jobs, then we can take CTM-current and >sup-current and reshape them for the needs of those who like to stay >up to date but not *that* up to date. Just judging by the amount of >push-back I've received over the years, I think that group of folks is >larger (and louder) than you think. It's probably time we sorted them >out, if for no other reason than to eliminate the 47 copies of >"-current is broken again!" messages we currently get on -current >(or -hackers, or both) whenever something breaks. :-) In defense of those who complain, I do not think it reasonable to expect to have to do a detective job every tine they get an update simply to get the thing to compile. This is particularly true when you consider that the build potentially "trashes" the working system. However, I also agree that "up-to-the-minute" is beyond the level that most people really need. When you ask that people run "current" so that you get some testing, they expect to test the workings of the driver, etc.; not the make tree. One advantage in going to this scheme is that you can eliminate the "sup" as a separate product target. The "up-to-the-minute" folks should use CVSup. The next level, including the sup servers, can use the ctm delineated "snapshots". The users can then either subscribe to ctm directly or sup the equivalent product. The next level would be the "Jordan's snapshot" which you have given a bit more testing than just "compiles". - - - I guess I see that you and I have a different viewpoint of the "stability" of things. In your model, "current" seems to be just some arbitrary collection of code. whereas "stable" has been tested enough to make sure it compiles and runs. You seem to leave out the "production" level which is supported. IMHO, it you want to build a following for the FreeBSD OS, you need to put greater emphasis on supported stability. I think that it is this market factor that you are hearing complain. From owner-freebsd-current Mon Sep 2 23:29:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA08169 for current-outgoing; Mon, 2 Sep 1996 23:29:29 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA08164 for ; Mon, 2 Sep 1996 23:29:27 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id GAA00926; Tue, 3 Sep 1996 06:29:04 GMT Date: Tue, 3 Sep 1996 15:29:03 +0900 (JST) From: Michael Hancock To: "Jordan K. Hubbard" cc: Terry Lambert , Kim Culhan , current@FreeBSD.org Subject: Re: Latest Current build failure In-Reply-To: <6742.841718920@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Sep 1996, Jordan K. Hubbard wrote: > > 24 hours, emitting an email at the end to know the central cookie > ^^^^let > > collector know the exit status of the build. If a majority of the > > Boy, I've gotta start checking my email more closely for typos... > Fast is nice, but that's too fast! :-) Spend some time in Japan and you start forgetting to use articles like 'a', 'an', or 'the'. I sometimes have to pause to remember how to spell simple words like 'wear'. I think writing code sometimes has the same effect. Regards, Mike Hancock From owner-freebsd-current Mon Sep 2 23:32:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA08282 for current-outgoing; Mon, 2 Sep 1996 23:32:06 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA08256 for ; Mon, 2 Sep 1996 23:31:56 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id IAA27371 for current@freebsd.org; Tue, 3 Sep 1996 08:15:33 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.5/8.7.3) with SMTP id IAA06304 for ; Tue, 3 Sep 1996 08:19:01 +0200 (MET DST) Date: Tue, 3 Sep 1996 08:19:01 +0200 (MET DST) From: Andreas Klemm To: current@freebsd.org Subject: is at(1) broken ? Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk root{1008} ~ at 0830 /usr/libexec/uucp/uucico -r1 -x2 -Seasix at: incomplete time root{1009} ~ at 0830am /usr/libexec/uucp/uucico -r1 -x2 -Seasix at: incomplete time root{1010} ~ at 830 /usr/libexec/uucp/uucico -r1 -x2 -Seasix at: incomplete time root{1011} ~ at 08:30 /usr/libexec/uucp/uucico -r1 -x2 -Seasix at: incomplete time Am I doing something wrong or is there something broken ?! andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Mon Sep 2 23:49:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA09398 for current-outgoing; Mon, 2 Sep 1996 23:49:46 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA09393 for ; Mon, 2 Sep 1996 23:49:43 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id GAA01050; Tue, 3 Sep 1996 06:49:27 GMT Date: Tue, 3 Sep 1996 15:49:27 +0900 (JST) From: Michael Hancock To: "Jordan K. Hubbard" cc: Terry Lambert , Kim Culhan , current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <6665.841718171@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Sep 1996, Jordan K. Hubbard wrote: > P.S. A human-driven model for this will *NOT* work. Such a > buildmeister person will simply burn out on the process in short > order, needlessly wasting everyone's time and one buildmeister. I agree. My post was meant to be illustrative of why current breaks what would be involved to fix it. Regards, Mike Hancock From owner-freebsd-current Tue Sep 3 01:27:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA13383 for current-outgoing; Tue, 3 Sep 1996 01:27:52 -0700 (PDT) Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA13378 for ; Tue, 3 Sep 1996 01:27:46 -0700 (PDT) Received: from marathon.tekla.fi by lassie.eunet.fi with SMTP id AB18280 (5.67a/IDA-1.5 for ); Tue, 3 Sep 1996 11:27:40 +0300 Received: from tahma.tekla.fi by marathon.tekla.fi (5.65/20-jun-90) id AA26651; Tue, 3 Sep 1996 11:27:36 +0300 Received: by tahma.tekla.fi (5.65v3.2/20-jun-90) id AA05232; Tue, 3 Sep 1996 11:27:34 +0300 Date: Tue, 3 Sep 1996 11:27:34 +0300 From: sja@tekla.fi (Sakari Jalovaara) Message-Id: <9609030827.AA05232@tahma.tekla.fi> To: current@FreeBSD.org Subject: Re: Latest Current build failure Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk How about this idea: Everyone cvsups the bleeding edge RCS files. If you want to live dangerously, you check out the most recent version and take your chances with compilation failures. Those who want "stable-current" check out a "latest known good" version and compile that. latest-known-good-date is created with Jordan's build box / cookie collector scheme. When everything compiles more-or-less ok, the checkout time of that version is saved. When you sup you get a file that contains that time. "make world" does co -d`cat /usr/src/compile-version-timestamp` in all directories. supping the checked-out source gives you stable-current - which is simply a checkout of the latest known good version. (Have mercy on me if this is totally silly - I'm new to FreeBSD and I'm not even using current - yet.) ++sja From owner-freebsd-current Tue Sep 3 01:37:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA13996 for current-outgoing; Tue, 3 Sep 1996 01:37:23 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA13991 for ; Tue, 3 Sep 1996 01:37:20 -0700 (PDT) From: garyj@frt.dec.com Received: from cssmuc.frt.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id EAA08201; Tue, 3 Sep 1996 04:33:16 -0400 (EDT) Received: from localhost by cssmuc.frt.dec.com; (5.65v3.2/1.1.8.2/14Nov95-0232PM) id AA05981; Tue, 3 Sep 1996 10:33:03 +0200 Message-Id: <9609030833.AA05981@cssmuc.frt.dec.com> X-Mailer: exmh version 1.6.4 10/10/95 To: current@freebsd.org In-Reply-To: Message from rkw@dataplex.net (Richard Wackerbarth) of Tue, 03 Sep 96 01:19:17 CDT. Reply-To: gjennejohn@frt.dec.com Subject: Re: Latest Current build failure Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Sep 96 10:33:03 +0200 X-Mts: smtp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk rkw@dataplex.net writes: > I guess I see that you and I have a different viewpoint of the "stability" > of things. > > In your model, "current" seems to be just some arbitrary collection of code. > whereas "stable" has been tested enough to make sure it compiles and runs. > You seem to leave out the "production" level which is supported. > > IMHO, it you want to build a following for the FreeBSD OS, you need to put > greater emphasis on supported stability. I think that it is this market > factor that you are hearing complain. > > IMO production level means release, not -current. I don't think that we can expect to grow a market based on -current, that's what the releases are for. People who want to be on the bleeding-edge and use -current have to enter this particular "hell" with open eyes. Using -current isn't for the faint of heart or newbies. I've been running -current for years and have never encountered a problem which wasn't quickly remedied in the tree or which I couldn't work around with little effort. I personally don't see investing a lot of time or resources to guarantee that -current is ALWAYS compilable. A hiccough now and then is what one has to expect and be prepared to accept when using -current. --- Gary Jennejohn (work) gjennejohn@frt.dec.com (home) Gary.Jennejohn@munich.netsurf.de (play) gj@freebsd.org From owner-freebsd-current Tue Sep 3 03:53:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA21396 for current-outgoing; Tue, 3 Sep 1996 03:53:13 -0700 (PDT) Received: from trinity.radio-do.de (fn@trinity.Radio-do.de [193.101.164.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA21387 for ; Tue, 3 Sep 1996 03:53:08 -0700 (PDT) Received: by trinity.radio-do.de (8.7.5/CLIENT-1.2.7-h) via EUnet id MAA07218; Tue, 3 Sep 1996 12:52:51 +0200 (MET DST) To: Andreas Klemm Cc: current@freebsd.org Subject: Re: is at(1) broken ? References: From: Frank Nobis Date: 03 Sep 1996 12:52:50 +0200 In-Reply-To: Andreas Klemm's message of Tue, 3 Sep 1996 08:19:01 +0200 (MET DST) Message-ID: Lines: 27 X-Mailer: Red Gnus v0.23/XEmacs 19.14 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Andreas" == Andreas Klemm writes: Andreas> root{1008} ~ at 0830 /usr/libexec/uucp/uucico -r1 -x2 -Seasix Andreas> at: incomplete time Andreas> root{1009} ~ at 0830am /usr/libexec/uucp/uucico -r1 -x2 -Seasix Andreas> at: incomplete time Andreas> root{1010} ~ at 830 /usr/libexec/uucp/uucico -r1 -x2 -Seasix Andreas> at: incomplete time Andreas> root{1011} ~ at 08:30 /usr/libexec/uucp/uucico -r1 -x2 -Seasix Andreas> at: incomplete time Andreas> Am I doing something wrong or is there something broken ?! As the manual told us: DESCRIPTION At and batch read commands from standard input or a specified file which are to be executed at a later time, using sh(1). Reading one command from the commandline would be a nice faeture, but is not implemented. Frank -- Frank Nobis Email: fn@Radio-do.de PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by FreeBSD Fax: +49 231 7213816 From owner-freebsd-current Tue Sep 3 04:59:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA24442 for current-outgoing; Tue, 3 Sep 1996 04:59:21 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA24437 for ; Tue, 3 Sep 1996 04:59:18 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id GAA13735; Tue, 3 Sep 1996 06:56:30 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 06:56:44 -0500 To: gjennejohn@frt.dec.com From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >IMO production level means release, not -current. I don't think that >we can expect to grow a market based on -current, that's what the >releases are for. People who want to be on the bleeding-edge and use >-current have to enter this particular "hell" with open eyes. Using >-current isn't for the faint of heart or newbies. I've been running >-current for years and have never encountered a problem which wasn't >quickly remedied in the tree or which I couldn't work around with >little effort. > >I personally don't see investing a lot of time or resources to >guarantee that -current is ALWAYS compilable. A hiccough now and >then is what one has to expect and be prepared to accept when using >-current. Well, "release" is not good enough for production. A release is static. There are always things wrong with a release. They need to be fixed. Newer versions of utilities need to be incorporated, etc. The present "stable" model could fill that slot. However, I would like to see a bit more effort placed on its support. (I know it isn't as much "fun" as working on "current") To me, there is a tradeoff between getting more "current" testers and allowing "current" to fail to compile. I personally think that "current" should be dropped. CVSup of the total tree is appropriate for the "bleeding edger's". At least they can then select which parts they wish to include in their build. The rest can wait for Jordan's SNAP releases. From owner-freebsd-current Tue Sep 3 05:10:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA24911 for current-outgoing; Tue, 3 Sep 1996 05:10:36 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA24906 for ; Tue, 3 Sep 1996 05:10:33 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id FAA09253; Tue, 3 Sep 1996 05:10:28 -0700 (PDT) To: rkw@dataplex.net (Richard Wackerbarth) cc: current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Tue, 03 Sep 1996 01:19:17 CDT." Date: Tue, 03 Sep 1996 05:10:28 -0700 Message-ID: <9251.841752628@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > One advantage in going to this scheme is that you can eliminate the "sup" > as a separate product target. > > The "up-to-the-minute" folks should use CVSup. > > The next level, including the sup servers, can use the ctm delineated > "snapshots". The users can then either subscribe to ctm directly or sup the > equivalent product. > > The next level would be the "Jordan's snapshot" which you have given a bit > more testing than just "compiles". Precisely. > I guess I see that you and I have a different viewpoint of the "stability" > of things. No, not really. > In your model, "current" seems to be just some arbitrary collection of code. > whereas "stable" has been tested enough to make sure it compiles and runs. > You seem to leave out the "production" level which is supported. Nope, that's not my model at all. Please, do not confuse policy which arises from a reasonable apprehension of the trade-offs involved in relying on volunteer labor and lots of midnight coding (a frequent necessity for those with day jobs) with any personal ideal. In my ideal world, all changes would be tested all the time and the tree would never break. I'm sure it's an ideal all of core shares, for that matter, but it's only an ideal. Cold, hard reality dictates that if you want forward progress from a large volunteer army of people then you can't threaten to blow their heads off every time they make a mistake while taking their own initiative on something - you *need* them to be willing to take their own initiative if any real progress is to be made. There are lots of ways in which even the very best programmers in this project can (and do) make mistakes which break -current. Fixing a mistake may be simple, but it still requires a finite amount of time. The simple fact of the matter is that there is no fool-proof method for preventing programmer errors, and providing on-the-fly access to the development sources opens us far wider than *any* commercial UN*X vendor to having "customers" trip over problems when they occur. Hell, the concept of "production level" doesn't even make sense when discussing what's essentially a live snapshot of the engineering team's working sources and, if anything, the real problem here is that the WRONG PEOPLE are running -current! If you've achieved nothing else, you've definitely made the point to me that we've got a serious image problem with -current these days, namely that it's entirely *too* visible. -current was truly never intended to be something that the general user population ran freely and considered to be some sort of technology worth tracking on a day-to-day basis. -current was started simply as a developer-to-developer service with a very small group of people both reading and writing to it, very much as the engineering source tree would be maintained within a small company. Once in awhile we'd make a snapshot of it and those snapshots were all the public ever saw. There are some significant advantages to doing things in this way, actually, among which are the facts that: 1. You don't spend a lot of time writing emails in justification for your latest change to the entire world (and someone, somewhere will *always* disagree with you - it's a statistical law), you just duke it out in private with a small group of developers who also know their way around the system pretty well. Bang-for-byte ratio in email high, developer satisfaction high. 2. You don't have a large user base to support with the source syncronization tools, it's just you and 10-20 others at most. Support email comprises a significantly smaller percentage of your incoming load as a result. 3. You can attempt radical changes and experiments, if desired, without having to first obtain the concensus of a small army. Larger scale improvements are given much more room to happen. However, evolution took different paths with the various *BSD groups, and in the FreeBSD Project we decided fairly early on that, despite the many clear and obvious advantages to "keeping it in the family", as it were, we felt they came at too high a cost in denying access to those who might derive legitimate benefit from access to all the latest bits. So we threw the doors open on -current, shouting loudly "No guarantees! This is nothing more than a ``look over our shoulders'' from a software developer's perspective, folks! No warrantee given or implied! Extremely slippery when wet!" and we later followed this with general access to the CVS repository itself. Despite all of our disclaimers, however, we also seem to have taken on a whole host of miserable, nasty side-effects which inevitably come from making decisions like this. The hundreds of emails from people running -current, many of whom have no business doing so (and are strongly and openly dissuaded from so doing in the Handbook's section on -current). The frequent shouting from the peanut gallery (no, of course I don't mean *you*, dear reader :-). The people whining about how the engineering sources aren't "production quality" enough, balanced only occasionally in volume by the other folks complaining that FreeBSD's not innovating fast enough and is full of stale source code direly in need of updating. Sigh. No matter what trade-offs one takes, it seems, there's at least one immutable constant: "Ya just can't win!" :-) Jordan From owner-freebsd-current Tue Sep 3 05:34:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA25962 for current-outgoing; Tue, 3 Sep 1996 05:34:13 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA25944 for ; Tue, 3 Sep 1996 05:34:09 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id OAA06757; Tue, 3 Sep 1996 14:33:59 +0200 Message-Id: <199609031233.OAA06757@ra.dkuug.dk> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 3 Sep 1996 14:33:59 +0200 (MET DST) Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <9251.841752628@time.cdrom.com> from "Jordan K. Hubbard" at Sep 3, 96 05:10:28 am From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who wrote: Lots of good explanaitons deleted... > Sigh. No matter what trade-offs one takes, it seems, there's at least > one immutable constant: "Ya just can't win!" :-) > > Jordan We have a law for that called "Jante loven"... :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-current Tue Sep 3 05:34:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA26003 for current-outgoing; Tue, 3 Sep 1996 05:34:57 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA25998 for ; Tue, 3 Sep 1996 05:34:55 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id FAA09342; Tue, 3 Sep 1996 05:34:35 -0700 (PDT) To: sja@tekla.fi (Sakari Jalovaara) cc: current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Tue, 03 Sep 1996 11:27:34 +0300." <9609030827.AA05232@tahma.tekla.fi> Date: Tue, 03 Sep 1996 05:34:35 -0700 Message-ID: <9340.841754075@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > latest-known-good-date is created with Jordan's build box / cookie > collector scheme. When everything compiles more-or-less ok, the > checkout time of that version is saved. When you sup you get a file > that contains that time. "make world" does > co -d`cat /usr/src/compile-version-timestamp` > in all directories. Actually, all you'd need to do is have your cvsup file modified to use a specific date in updating a previously checked out version of HEAD. I think. John, would that work? :-) Jordan From owner-freebsd-current Tue Sep 3 05:54:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA27011 for current-outgoing; Tue, 3 Sep 1996 05:54:49 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA27006 for ; Tue, 3 Sep 1996 05:54:47 -0700 (PDT) Received: from downlink.eng.umd.edu (downlink.eng.umd.edu [129.2.98.182]) by po1.glue.umd.edu (8.8.Beta.0/8.7.3) with ESMTP id IAA12739; Tue, 3 Sep 1996 08:54:43 -0400 (EDT) Received: from localhost (chuckr@localhost) by downlink.eng.umd.edu (8.7.5/8.7.3) with SMTP id IAA17889; Tue, 3 Sep 1996 08:54:42 -0400 (EDT) X-Authentication-Warning: downlink.eng.umd.edu: chuckr owned process doing -bs Date: Tue, 3 Sep 1996 08:54:41 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@downlink.eng.umd.edu To: Richard Wackerbarth cc: gjennejohn@frt.dec.com, current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 3 Sep 1996, Richard Wackerbarth wrote: > >IMO production level means release, not -current. I don't think that > >we can expect to grow a market based on -current, that's what the > >releases are for. People who want to be on the bleeding-edge and use > >-current have to enter this particular "hell" with open eyes. Using > >-current isn't for the faint of heart or newbies. I've been running > >-current for years and have never encountered a problem which wasn't > >quickly remedied in the tree or which I couldn't work around with > >little effort. > > > >I personally don't see investing a lot of time or resources to > >guarantee that -current is ALWAYS compilable. A hiccough now and > >then is what one has to expect and be prepared to accept when using > >-current. > > Well, "release" is not good enough for production. A release is static. > There are always things wrong with a release. They need to be fixed. Newer > versions of utilities need to be incorporated, etc. > > The present "stable" model could fill that slot. However, I would like to > see a bit more effort placed on its support. (I know it isn't as much "fun" > as working on "current") > > To me, there is a tradeoff between getting more "current" testers and > allowing "current" to fail to compile. I personally think that "current" > should be dropped. CVSup of the total tree is appropriate for the "bleeding > edger's". > At least they can then select which parts they wish to include in their build. > The rest can wait for Jordan's SNAP releases. You know, I'm just a little curious about the tone of the argument. While I do think that current has gone through some very bad periods of instability, I don't remember a time that it was as stable as it has been lately. The clear majority of problems in building current have been related to sup archive instability, not current being broke, I think your goals are laudable, but they don't seem to be addressing the problem right now. I am wondering if a rapid checksum program wouldn't be of more general use right now, so folks could elilminate archive problems before complaining that current is broke. I'm running ctm/cvs myself, and current has been incredibly stable. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Tue Sep 3 05:59:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA27097 for current-outgoing; Tue, 3 Sep 1996 05:59:05 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA27089 for ; Tue, 3 Sep 1996 05:59:03 -0700 (PDT) From: garyj@frt.dec.com Received: from cssmuc.frt.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id IAA28280; Tue, 3 Sep 1996 08:51:41 -0400 (EDT) Received: from localhost by cssmuc.frt.dec.com; (5.65v3.2/1.1.8.2/14Nov95-0232PM) id AA19998; Tue, 3 Sep 1996 14:51:39 +0200 Message-Id: <9609031251.AA19998@cssmuc.frt.dec.com> X-Mailer: exmh version 1.6.4 10/10/95 To: current@freebsd.org In-Reply-To: Message from "Jordan K. Hubbard" of Tue, 03 Sep 96 05:10:28 PDT. Reply-To: gjennejohn@frt.dec.com Subject: Re: Latest Current build failure Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Sep 96 14:51:38 +0200 X-Mts: smtp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk jkh@time.cdrom.com writes: [deletia] > Hell, the concept of "production level" doesn't even make sense when > discussing what's essentially a live snapshot of the engineering > team's working sources and, if anything, the real problem here is that > the WRONG PEOPLE are running -current! > [more deletia] you hit the nearly *very* squarely on the head. I wonder if this shouldn't be moved to chat ? Or better yet, dropped ? --- Gary Jennejohn (work) gjennejohn@frt.dec.com (home) Gary.Jennejohn@munich.netsurf.de (play) gj@freebsd.org From owner-freebsd-current Tue Sep 3 06:01:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA27257 for current-outgoing; Tue, 3 Sep 1996 06:01:54 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA27250 for ; Tue, 3 Sep 1996 06:01:51 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id HAA14313; Tue, 3 Sep 1996 07:59:18 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 07:59:17 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Food for thought Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" writes: > Nope, that's not my model at all. Please, do not confuse policy which > arises from a reasonable apprehension of the trade-offs involved in > relying on volunteer labor and lots of midnight coding (a frequent > necessity for those with day jobs) with any personal ideal. I'm not saying that you consider it a good "model", but rather that it is the model of the reality of the situation. I'm sure that YOU would prefer something that works a bit better. The Lord knows that you spend entirely too much time transforming this chaos into something that can be sold. There certainly is no "right" answer that satisfys everyone. >Sigh. No matter what trade-offs one takes, it seems, there's at least >one immutable constant: "Ya just can't win!" :-) Amen. There are a few policies that I think lead to some of the problem. 1) Although I like the idea that "current" is readily available, forcing new development to be done against it leads, IMHO, to making people use something which is more unstable than what they need or desire. The tradeoff is in the integration. 2) The relative reluctance to attempt to support "released" systems. There appears to be an attitude of "shipped and forgotten". 3) The extremely short test cycle for new releases. IMHO, we should already have a feature freeze for 2.2 and the leading edge should be planning for 2.3. 4) It's too hard for the "average Joe" to isolate various parallel developments. Often the "unbuildability" of current bounces from one camp to another. Just about the time one problem gets cleaned up, something crops up in another area. 5) Unfortunately, only a few of us can afford to have spare machines to "burn" on instability. How often do we see somebody limping along without adequate HD? From owner-freebsd-current Tue Sep 3 07:08:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA00540 for current-outgoing; Tue, 3 Sep 1996 07:08:00 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA00534 for ; Tue, 3 Sep 1996 07:07:55 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id XAA28427; Tue, 3 Sep 1996 23:37:39 +0930 From: Michael Smith Message-Id: <199609031407.XAA28427@genesis.atrad.adelaide.edu.au> Subject: Re: Food for thought To: rkw@dataplex.net (Richard Wackerbarth) Date: Tue, 3 Sep 1996 23:37:39 +0930 (CST) Cc: jkh@time.cdrom.com, current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Sep 3, 96 07:59:17 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth stands accused of saying: > > 1) Although I like the idea that "current" is readily available, forcing > new development to be done against it leads, IMHO, to making people use > something which is more unstable than what they need or desire. The > tradeoff is in the integration. Bollocks. -current is _incredibly_ stable for what is a running second-by-second snapshot of a development tree in full swing. Being aware of the risks, and keeping an eye on the commit mailing lists, I have little or no trouble keeping half a dozen -current systems less than a week out of sync. I don't think I've had any serious problems with -current being anything other than temporarily unstable for many many months now. It's certainly a perfectly adequate platform for development. > 2) The relative reluctance to attempt to support "released" systems. There > appears to be an attitude of "shipped and forgotten". Ever worked for a major software vendor? Ever been one of their victims? Where were you when -stable split off ~12mo ago, putting in the hard yards pulling fixes from the development tree (where they belong) and shadowing them through to the post-release tree? Hmm? > 3) The extremely short test cycle for new releases. IMHO, we should already > have a feature freeze for 2.2 and the leading edge should be planning for > 2.3. Ah, I see an offer of the Release Engineer's hat heading your way. My advice is, duck. > 4) It's too hard for the "average Joe" to isolate various parallel > developments. Often the "unbuildability" of current bounces from one camp > to another. Just about the time one problem gets cleaned up, something > crops up in another area. -current hasn't been severely "unbuildable" for a considerable time. The usual problem is that some twonk says 'make world', and when it dies _immediately_ posts to the list whining. The correct procedure in this case is : - sup again. If you sup regularly, even if your link is a piece of wet string, a resup to get yourself in sync won't take very long. - try your build again. - try 'make bootstrap;make world' - most importantly : wait 24 hours and repeat the process. DO NOT go off abusing people of 'not testing' their code until you are sure beyond all reasonable doubt that it's not _your_ fault. You look _stupid_ when you do. (Believe me, I know 8) and if all else fails : - read the error messages. Cross-correlate between recent commits (You _do_ read the commit lists, right?), and talk directly to recent committers in the affected area. > 5) Unfortunately, only a few of us can afford to have spare machines to > "burn" on instability. How often do we see somebody limping along without > adequate HD? Given the incredibly high level of overall abstraction and interoperability, it's quite reasonable to mix-n-match several different sets of bits and pieces in adequate harmony. Sure, there may be room for improvement. But bitching about it is NOT the right way to go about fixing anything. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Tue Sep 3 08:32:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA05289 for current-outgoing; Tue, 3 Sep 1996 08:32:16 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA05264 for ; Tue, 3 Sep 1996 08:32:09 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id IAA09740; Tue, 3 Sep 1996 08:32:04 -0700 (PDT) To: rkw@dataplex.net (Richard Wackerbarth) cc: current@freebsd.org Subject: Re: Food for thought In-reply-to: Your message of "Tue, 03 Sep 1996 07:59:17 CDT." Date: Tue, 03 Sep 1996 08:32:04 -0700 Message-ID: <9738.841764724@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There are a few policies that I think lead to some of the problem. I agree that most of these things are true problems, though I'm not sure they all point back to the same common solution. More specifically: > 1) Although I like the idea that "current" is readily available, forcing > new development to be done against it leads, IMHO, to making people use > something which is more unstable than what they need or desire. The You have this inverted. New development has to go somewhere, it not being a question of "forcing" anything, and it's the *inappropriate* use of -current by some which is the real problem. In that we're not providing them with an alternative other than the previous release, I suppose it could be said that we are "making people use something which use more unstable ...", but even the answer there is not to alter -current, it's to offer the new "metered -current" service I proposed at the beginning of this whole thread. > 2) The relative reluctance to attempt to support "released" systems. There > appears to be an attitude of "shipped and forgotten". Not in this neck of the woods, they're not. I spend most of my tech support work dealing with the most recent release, as do quite a few others. Nobody I know on the core team takes this attitude, that's for sure. > 3) The extremely short test cycle for new releases. IMHO, we should already > have a feature freeze for 2.2 and the leading edge should be planning for > 2.3. While I agree that some of the recent "test cycles" were too short, each feature freeze date is something that has to be derived more from instinct than formula. Again, these are volunteers here and they work in ways different than what you'd typically expect from a paid development team. During feature freezes, when work is constrained to relatively boring stuff, the pace and scale of contributions slows down comeasurately. There's a certain point where the lines cross on the graph and beyond you could have a 6 month freeze, but only 4 changes would be committed during that time and most of the active development projects mysteriously abandoned. Flexibility is sometimes more important than a rigid release ideology if you want to keep having releases in another year's time. > 4) It's too hard for the "average Joe" to isolate various parallel > developments. Often the "unbuildability" of current bounces from one camp Exactly, which is why the average Joe should stick with the latest -release and wait for us to get our acts together on implementing a system for getting only critical bug fixes to him. > 5) Unfortunately, only a few of us can afford to have spare machines to > "burn" on instability. How often do we see somebody limping along without > adequate HD? Thankfully rather less often since 2Gb SCSI drives fell through the $400 mark. Jordan From owner-freebsd-current Tue Sep 3 08:47:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA06014 for current-outgoing; Tue, 3 Sep 1996 08:47:34 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA06002; Tue, 3 Sep 1996 08:47:27 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id RAA06312; Tue, 3 Sep 1996 17:46:52 +0200 (MET DST) To: Michael Smith cc: rkw@dataplex.net (Richard Wackerbarth), jkh@time.cdrom.com, current@FreeBSD.org Subject: Re: Food for thought In-reply-to: Your message of "Tue, 03 Sep 1996 23:37:39 +0930." <199609031407.XAA28427@genesis.atrad.adelaide.edu.au> Date: Tue, 03 Sep 1996 17:46:51 +0200 Message-ID: <6310.841765611@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199609031407.XAA28427@genesis.atrad.adelaide.edu.au>, Michael Smith writes: >> 3) The extremely short test cycle for new releases. IMHO, we should already >> have a feature freeze for 2.2 and the leading edge should be planning for >> 2.3. > >Ah, I see an offer of the Release Engineer's hat heading your way. My >advice is, duck. Only if he teams up with Terry as Q/A controller and we have a spare hat! Listen, it's really VERY VERY SIMPLE! We don't promise anything about -current, nothing, absolutely NOTHING! If you have trouble with -current, you'd better find out for your self what they are, and send an email with a patch, or at least >very< precise description to the committer you think is responsible. Otherwise: Get of our back! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Sep 3 08:49:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA06217 for current-outgoing; Tue, 3 Sep 1996 08:49:59 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA06208 for ; Tue, 3 Sep 1996 08:49:55 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id JAA26803 for ; Tue, 3 Sep 1996 09:49:53 -0600 (MDT) Message-Id: <199609031549.JAA26803@rover.village.org> Subject: Re: Food for thought To: current@FreeBSD.org In-reply-to: Your message of Tue, 03 Sep 1996 23:37:39 +0930 Date: Tue, 03 Sep 1996 09:49:53 -0600 From: Warner Losh Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk CVS tree takes an extra 250M of hard disk. That's still $50 worth of hard disk, but you have to buy it in $200-$300 chunks, which can be hard for people. Or run the risk of the used market... That said, I recently bought more disk (a Jaz drive), and have been very happy with CTM of CVS. I've not had any make worlds fail since I've moved over to that which weren't the result of disk full failures. If you are going to play the -current game, you need at least 2.0G of disk available. 700M for CVS + source + obj and 1.3 to do your real work on :-) IMHO, of course. One thing I really *LIKE* about OpenBSD's anoncvs is that you can grab a *SUBSET* of the tree and not have to pay the price of having both the CVS tree and the whole source tree online. If someone were really upset about the current build situation, purhaps their energies might be better spent setting up an experimental anoncvs server fed off a ctm maintained CVS tree so that the FreeBSD community might benefit from that. Just some random thoughts... Warner From owner-freebsd-current Tue Sep 3 08:58:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA06985 for current-outgoing; Tue, 3 Sep 1996 08:58:45 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA06972; Tue, 3 Sep 1996 08:58:41 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id RAA06450; Tue, 3 Sep 1996 17:58:07 +0200 (MET DST) To: Warner Losh cc: current@FreeBSD.org Subject: Re: Food for thought In-reply-to: Your message of "Tue, 03 Sep 1996 09:49:53 MDT." <199609031549.JAA26803@rover.village.org> Date: Tue, 03 Sep 1996 17:58:06 +0200 Message-ID: <6448.841766286@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199609031549.JAA26803@rover.village.org>, Warner Losh writes: >[...] If someone were really >upset about the current build situation, purhaps their energies might >be better spent setting up an experimental anoncvs server fed off a >ctm maintained CVS tree so that the FreeBSD community might benefit >from that. This reflects an attitude that is in need for much more propagation than it currently gets: FreeBSD slogan (proposed): "If it's broken: don't whine, go fix it!" >Just some random thoughts... Not at all random! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Sep 3 09:08:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07892 for current-outgoing; Tue, 3 Sep 1996 09:08:04 -0700 (PDT) Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA07746 for ; Tue, 3 Sep 1996 09:08:02 -0700 (PDT) Received: from srmail.sr.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA176316805; Tue, 3 Sep 1996 09:06:46 -0700 Received: from hpnmhjw.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA128176801; Tue, 3 Sep 1996 09:06:41 -0700 Received: from mina.sr.hp.com by hpnmhjw.sr.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA279966800; Tue, 3 Sep 1996 09:06:40 -0700 Message-Id: <199609031606.AA279966800@hpnmhjw.sr.hp.com> To: Seppo Kallio Cc: current@freefall.freebsd.org Subject: Re: Format of FreeBSD 2.2-current cdrom In-Reply-To: Your message of "Mon, 02 Sep 1996 14:01:55 +0300." Date: Tue, 03 Sep 1996 09:06:40 -0700 From: Darryl Okahata Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I want to make my own special FreeBSD CD ROM. Can some one tell me how > should the directory tree look to get for ex. 2.2-960801-SNAP boot floppy > to work and install from my own CD ROM. > > Does it start /dists/2.2-960801-SNAP/ and then continue as in ftp > archives, that is something like: I think it starts with "/2.2-960801-SNAP". However, I just put these in the top-level ("/") CDROM directory: > HARDWARE.TXT RELNOTES.TXT compat20/ info/ src/ > INSTALL.TXT XF86312@ des/ manpages/ xperimnt/ > MIRROR.SITES bin/ dict/ packages@ > README.TXT commerce/ floppies/ ports@ > READNOW.TXT compat1x/ games/ proflibs/ and add this to the top-level ("/") directory: ln -s . 2.2-960801-SNAP (I like having everything in the top-level directory, and so I do it this way. I know this works, as I did the 2.2-960801-SNAP upgrade from a CDROM made this way.) However, don't use any symlinks unless you want them put onto the CDROM. In particular, you probably want XF86312, packages, and ports to be the actual directories, and not symlinks (as you have them shown, above). [ For that matter, you probably don't want xperimnt and packages, as these are pretty huge. ] -- Darryl Okahata darrylo@sr.hp.com http://web.sr.hp.com/~darrylo/ From owner-freebsd-current Tue Sep 3 09:15:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08420 for current-outgoing; Tue, 3 Sep 1996 09:15:25 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA08411 for ; Tue, 3 Sep 1996 09:15:23 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA25571; Tue, 3 Sep 1996 10:15:05 -0600 (MDT) Date: Tue, 3 Sep 1996 10:15:05 -0600 (MDT) Message-Id: <199609031615.KAA25571@rocky.mt.sri.com> From: Nate Williams To: Warner Losh Cc: current@freebsd.org Subject: Re: Food for thought In-Reply-To: <199609031549.JAA26803@rover.village.org> References: <199609031549.JAA26803@rover.village.org> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > One thing I really *LIKE* about OpenBSD's anoncvs is that you can grab > a *SUBSET* of the tree and not have to pay the price of having both > the CVS tree and the whole source tree online. By tweaking your CVS supfile, you can get a subset of the CVS tree as well. Heck, if you *really* wanted to, you could get a mix of the CVS tree bits and the non-CVS (source) bits if disk space is really tight. Flexibility is the key here, and all the solutions (except for CTM) allow for mixing and matching distribution bits. Nate From owner-freebsd-current Tue Sep 3 09:49:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA10789 for current-outgoing; Tue, 3 Sep 1996 09:49:00 -0700 (PDT) Received: from night.primate.wisc.edu (night.primate.wisc.edu [144.92.43.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA10784 for ; Tue, 3 Sep 1996 09:48:55 -0700 (PDT) Received: by night.primate.wisc.edu; id LAA27866; 8.6.10/41.8; Tue, 3 Sep 1996 11:50:09 -0500 From: Paul DuBois Message-Id: <199609031650.LAA27866@night.primate.wisc.edu> Subject: Re: Food for thought To: imp@village.org (Warner Losh) Date: Tue, 3 Sep 1996 11:50:09 -0500 (CDT) Cc: current@freebsd.org In-Reply-To: <199609031549.JAA26803@rover.village.org> from "Warner Losh" at Sep 3, 96 09:49:53 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >That said, I recently bought more disk (a Jaz drive), and have been >very happy with CTM of CVS. I've not had any make worlds fail since >I've moved over to that which weren't the result of disk full >failures. Had you had problems with FreeBSD locking up if the Jaz has to be brought out of sleep mode? (I'm running 2.1 but) I've seen this in two contexts: 1) During a FreeBSD install. I got to the point where the install process began loading my selected subsets. This was going to take a while, so I went away. Then I can back and was ready to finish up. At some point during the finish-up, the Jaz got woken up, at which point the install hung. (I wasn't installing to the Jaz, by the way.) 2) During bootup. The SCSI probe part of the bootup process woke a sleeping Jaz, a command timeout and abort occurred, and the boot process was hung. Does -current handle these situations better? This was on a Dell OptiPlex with Adaptec 2940UW. In both cases a power cycle was necessary to restart the machine. From owner-freebsd-current Tue Sep 3 09:52:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA11006 for current-outgoing; Tue, 3 Sep 1996 09:52:39 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA11001 for ; Tue, 3 Sep 1996 09:52:36 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id KAA27084; Tue, 3 Sep 1996 10:52:19 -0600 (MDT) Message-Id: <199609031652.KAA27084@rover.village.org> To: Paul DuBois Subject: Re: Food for thought Cc: current@freebsd.org In-reply-to: Your message of Tue, 03 Sep 1996 11:50:09 CDT Date: Tue, 03 Sep 1996 10:52:19 -0600 From: Warner Losh Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk : Does -current handle these situations better? I've seen reports of problems with 2.1 and some versions of stable (like until early spring). My -current box from July onward has been happy as a clam with the Jaz drive, even with sleep mode. I've not tried 2.1.5R, but I have reason to believe that it works there as well. Warner From owner-freebsd-current Tue Sep 3 10:45:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA14270 for current-outgoing; Tue, 3 Sep 1996 10:45:19 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA14262 for ; Tue, 3 Sep 1996 10:45:13 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.7.5/8.6.9) with SMTP id SAA00335 for ; Tue, 3 Sep 1996 18:44:29 +0100 (BST) Date: Tue, 3 Sep 1996 18:44:29 +0100 (BST) From: Developer To: freebsd-current@freebsd.org Subject: HELP URGENT!!! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please can someone suggest what to do... our BSD 2.2 server crashed and when we re-booted we get this error as soon as fsck kicks in:- Debugger("sd") Stopped at _Debugger+0x26: movb $0,_in_Debugger.116 db> If I then type cont I get: Can't open /dev/rsd2a Device not configured. In /var/log/messages there is this error:- /kernel: sd2: Can't deal with 767 bytes logical blocks Seems like the disklabel is dodgy :( Any ideas how to fix it? It's desperate?? Regards, Trefor S. From owner-freebsd-current Tue Sep 3 11:12:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA16005 for current-outgoing; Tue, 3 Sep 1996 11:12:44 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA15994 for ; Tue, 3 Sep 1996 11:12:38 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA04620; Tue, 3 Sep 1996 11:08:58 -0700 From: Terry Lambert Message-Id: <199609031808.LAA04620@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 3 Sep 1996 11:08:57 -0700 (MST) Cc: michaelh@cet.co.jp, terry@lambert.org, kimc@w8hd.org, current@FreeBSD.org In-Reply-To: <6665.841718171@time.cdrom.com> from "Jordan K. Hubbard" at Sep 2, 96 07:36:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 3. The "slow update" of the -current tree on freefall, from which the > sup and CTM services are provided, is driven by a "cookie collector" > process - some PERL script hanging off an email alias which collects > success-or-fail messages from a set of designated build boxes. > Each designated build box, some of which we could provide here at WC, > commits to updating to and building the CVS HEAD branch once every > 24 hours, emitting an email at the end to know the central cookie > collector know the exit status of the build. If a majority of the > build boxes report success during a given 24 hour period, and I'd > recommend making it a majority vote since a given percentage will > *always* be hosed due to local stupidity of some sort, then the > for-public-consumption tree will be updated. Why do you need more than one build box? Is it because the snapshot from the tree is made on each download request instead of on a timed copy of the tree? I think a more reasonable, one machine, version would be: 1) wait some interval 2) copy active cvs tree to static cvs tree 3) test-build static cvs tree 4) if test-build fails, go to 1 5) copy successfully test-built static cvs tree to distribution cvs tree 6) people download distribution cvs tree Posits: a) the interval in step 1 should be as short as step 3 allows b) access to the distribution cvs tree should be blocked during step 5; this could be implemented with a simple access lock protocol obeyed by the copy process and the download process(es) c) we would prefer to block modification by programmers to the active cvs tree during step 2 to ensure an increased likelihood of buildability; a reader/writer lock would provide a guarantee here -- note, again: the guarantee is not necessary, only desirable d) assuming locing protocols, it's possible to split the process once per additional build machine, as a divisor into the interval in step 1: this could reduce the overall turnaround time between an active tree modification becoming available Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 3 11:57:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA18685 for current-outgoing; Tue, 3 Sep 1996 11:57:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA18680 for ; Tue, 3 Sep 1996 11:57:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA04805; Tue, 3 Sep 1996 11:55:21 -0700 From: Terry Lambert Message-Id: <199609031855.LAA04805@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: smpatel@umiacs.umd.edu (Sujal Patel) Date: Tue, 3 Sep 1996 11:55:21 -0700 (MST) Cc: jkh@time.cdrom.com, current@freebsd.org In-Reply-To: from "Sujal Patel" at Sep 2, 96 11:11:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Mon, 2 Sep 1996, Jordan K. Hubbard wrote: > > > > I haven't seen any real solutions to the buildable-current problem. > > > > Actually, I've been proposing a solution for close to 2 years now, > > we've just never actually set about the process of implementing it. > > Perhaps it's just me, but I really don't expect current to build all the > time. It's just a fact of life... That's why it's called -current. > > If you really need something that's in -current, then just wait for the > 2.2 SNAPS, they are fairly regular. So make up a name somewhere between "-current" and "2.2 SNAPS", with the primary criteria being that you expect it to build all the time. Then we can complain about that. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 3 12:04:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA19042 for current-outgoing; Tue, 3 Sep 1996 12:04:27 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA19035 for ; Tue, 3 Sep 1996 12:04:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA04818; Tue, 3 Sep 1996 12:02:35 -0700 From: Terry Lambert Message-Id: <199609031902.MAA04818@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 3 Sep 1996 12:02:35 -0700 (MST) Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <9251.841752628@time.cdrom.com> from "Jordan K. Hubbard" at Sep 3, 96 05:10:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The simple fact of the matter is that there is no fool-proof method > for preventing programmer errors, and providing on-the-fly access to > the development sources opens us far wider than *any* commercial UN*X > vendor to having "customers" trip over problems when they occur. There are writer locks which you are not permitted to release until a full build succeeds. But of course, that's shot down each time it is brought up. At Novell, using CVS with a reader/writer lock front end, we were able to keep a project with 18+ engineers hacking on it 8-12 hours a day buildable for every night but 5 for a period of 8 months. Further, we did it on three machine architectures. This is a heck of a lot more variance than is experienced by the FreeBSD project. It is nothing more than a matter of self-discipline combined with some simple tool changes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 3 12:06:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA19216 for current-outgoing; Tue, 3 Sep 1996 12:06:16 -0700 (PDT) Received: from watson.grauel.com (watson.grauel.com [199.233.104.36]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA19211 for ; Tue, 3 Sep 1996 12:06:14 -0700 (PDT) Received: (from rjk@localhost) by watson.grauel.com (8.7.5/8.7.3) id OAA14297; Tue, 3 Sep 1996 14:12:10 -0500 (EST) Date: Tue, 3 Sep 1996 14:12:10 -0500 (EST) Message-Id: <199609031912.OAA14297@watson.grauel.com> From: Richard J Kuhns To: freebsd-current@freebsd.org Subject: Question about ctm and the 960801-SNAP CD Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Apologies if this has already been mentioned -- I subscribe to -current and -cvs-all, but I may have missed it. I've just received the SNAP CD, and I'd like to install it on my home machine && start tracking -current via ctm; I've also just subscribed to ctm-src-cur. Rather than download the 30MB src-2.2-2100A.gz `starter', I hope I can start with the sources on the CD and just apply the updates since the CD was pressed. Can anyone tell me which update I should start with? I tried searching the archives using the keyword "960801-SNAP", but I couldn't find anything relevant. (Hey Jordan -- that'd be a really useful piece of info to stick in RELNOTES.TXT ;-). My home machine (moran) is very well backed up; I intend to upgrade by going thru the Novice install && telling sysinstall to newfs root, /usr, and /var. If, in the interest of testing code anywhere, someone would like me to try something different, please let me know. I'll include the current dmesg output from my most recent reboot below. Thanks for any help... === FreeBSD 2.1-STABLE #0: Fri Aug 16 20:22:40 EST 1996 rjk@moran.grauel.com:/usr/src/sys/compile/MORAN CPU: 120-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30633984 (29916K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7:0 chip2 rev 2 on pci0:7:1 vga0 rev 0 int a irq 10 on pci0:10 bt0 rev 0 int a irq 11 on pci0:12 bt0: Bt946C/ 0-(32bit) bus bt0: reading board settings, dma=5, int=11 bt0: version 4.25J, fast sync, parity, 32 mbxs, 32 ccbs bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 bt0: targ 1 sync rate=10.00MB/s(100ns), offset=15 bt0: targ 6 async bt0: Using Strict Round robin scheme bt0 waiting for scsi devices to settle (bt0:0:0): "SEAGATE ST32550N 0014" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 2047MB (4194058 512 byte sectors) (bt0:1:0): "SEAGATE ST32550N 0011" type 0 fixed SCSI 2 sd1(bt0:1:0): Direct-Access 2047MB (4194058 512 byte sectors) (bt0:6:0): "ARCHIVE VIPER 2525 25462 -007" type 1 removable SCSI 1 st0(bt0:6:0): Sequential-Access density code 0x0, drive empty Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> pca0 on motherboard pca0: PC speaker audio driver sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in matcd - Matsushita (Panasonic) CD-ROM Driver by FDIV, Version 1(26) 18-Oct-95 matcdc0 at 0x230-0x233 on isa matcdc0 Host interface type 0 matcd0: [CR-5630.75] sb0 at 0x220 irq 5 drq 1 on isa sb0: sbxvi0 at 0x0 drq 6 on isa sbxvo0: sbmidi0 at 0x300 on isa npx0 on motherboard npx0: INT 16 interface -- Rich Kuhns rjk@grauel.com PO Box 6249 Tel: (317)477-6000 \ 100 Sawmill Road x319 Lafayette, IN 47903 (800)489-4891 / From owner-freebsd-current Tue Sep 3 12:08:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA19388 for current-outgoing; Tue, 3 Sep 1996 12:08:44 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA19379 for ; Tue, 3 Sep 1996 12:08:40 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA22742; Tue, 3 Sep 1996 12:07:10 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) by whistle.com via smap (V1.3) id sma022740; Tue Sep 3 12:07:01 1996 Message-ID: <322C818E.167EB0E7@whistle.com> Date: Tue, 03 Sep 1996 12:05:50 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Developer CC: freebsd-current@freebsd.org Subject: Re: HELP URGENT!!! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Developer wrote: > > Please can someone suggest what to do... our BSD 2.2 server crashed and > when we re-booted we get this error as soon as fsck kicks in:- > > Debugger("sd") > Stopped at _Debugger+0x26: movb $0,_in_Debugger.116 > db> > > If I then type cont I get: > > Can't open /dev/rsd2a Device not configured. > > In /var/log/messages there is this error:- > > /kernel: sd2: Can't deal with 767 bytes logical blocks this message doesn't come from the label, but from the disk driver when it asks the drive how it is formatted.. /* * Load the physical device parameters */ sd_get_parms(unit, 0); /* sets SDEV_MEDIA_LOADED */ if (sd->params.secsiz != SECSIZE) { /* XXX One day... */ printf("sd%ld: Can't deal with %d bytes logical blocks\n", unit, sd->params.secsiz); Debugger("sd"); here is the debugger call.. the original intention is to let you examine the results from the sd_get_params call errcode = ENXIO; goto bad; } Your disk has been "partially reformetted" OR it's gone crazy OR sd_get_parms(unit,0) is returning garbage (probably also due to a mad disk) > > Seems like the disklabel is dodgy :( nope.. see above.. > > Any ideas how to fix it? It's desperate?? compile a kernel with the SCSIDEBUG then after booting do: scsi -d 15 -f /dev/rsd2.ctl this will turn on TONS of debugging if it's too much -d 1 might be better this should give you the results of all operations affecting that device... julian in the mean-while don't write to that device (not that it'll let you :) get a new disk? > > Regards, > > Trefor S. From owner-freebsd-current Tue Sep 3 12:23:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA20092 for current-outgoing; Tue, 3 Sep 1996 12:23:34 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA20084 for ; Tue, 3 Sep 1996 12:23:31 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id VAA22865 for ; Tue, 3 Sep 1996 21:23:20 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id VAA17178 for current@freebsd.org; Tue, 3 Sep 1996 21:22:53 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Beta.1/keltia-uucp-2.9) id TAA17395; Tue, 3 Sep 1996 19:54:14 +0200 (MET DST) Message-Id: <199609031754.TAA17395@keltia.freenix.fr> Date: Tue, 3 Sep 1996 19:54:13 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: ; from Chuck Robey on Sep 3, 1996 8:54:41 -0400 References: X-Mailer: Mutt 0.41 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2415 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Chuck Robey: > I'm running ctm/cvs myself, and current has been incredibly stable. I don't want to add too much fuel to the discussion but I agree with Chuck here. CURRENT is stable for me too. People who can't bear to have the tree broken for a few hours without complaining should either stop running CURRENT or provide a fix if they can't wait for the next sup/ctm. "Bleeding edge" has _bleeding_ in it. It seems that people tend to forget that. I agree with Jordan that in an ideal world, it would be buildable at any time but we live in a practical one; a few hic-hup are to be expected. One should live with it or use only snapshots/releases... 2 cts from a happy CURRENT user. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #20: Fri Aug 30 23:00:02 MET DST 1996 From owner-freebsd-current Tue Sep 3 12:24:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA20183 for current-outgoing; Tue, 3 Sep 1996 12:24:37 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA20169 for ; Tue, 3 Sep 1996 12:24:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA04862; Tue, 3 Sep 1996 12:19:23 -0700 From: Terry Lambert Message-Id: <199609031919.MAA04862@phaeton.artisoft.com> Subject: Re: Food for thought To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 3 Sep 1996 12:19:23 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, rkw@dataplex.net, jkh@time.cdrom.com, current@FreeBSD.org In-Reply-To: <6310.841765611@critter.tfs.com> from "Poul-Henning Kamp" at Sep 3, 96 05:46:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Listen, it's really VERY VERY SIMPLE! We don't promise anything about > -current, nothing, absolutely NOTHING! > > If you have trouble with -current, you'd better find out for your self > what they are, and send an email with a patch, or at least >very< precise > description to the committer you think is responsible. > > Otherwise: Get of our back! The problem is not one of meeting promises which you have outstanding; I will be the first to agree that there are no promises out there which you should feel compelled to meet, in regard to -current. On the other hand, I think that there is general agreement the overall group effort can be made to move more effectively toward the combined project goals if -current compiles. I'm not suggesting that it would then have to *run*. *That* would be trying to make -current into "production level code", which I agree, would be a mistake. On the other hand, every 3-4 months, -current goes through a period of instability, we all have this very argument, people get their sensibilities offended, and then they set about proving we don't need any "grandios schemes" by increasing their own dilligence. And things improve for 3-4 months until. once again, the dilligence slips. The problem is that there is a human dilligence requirement that needs to be removed from human control and ensconced in the process itself so that a human failure will not cause a failure of credibility. I have made my own suggestions on this several 3-4 month periods in the past, on several occasions, already. I'd be perfectly happy to see *any* soloution: it does not have to be mine, and I'll stop advocating mine if it will help pave the road to *some* soloution. Frankly, I find it apalling to have the *possibility* of a source repository *ever* in an unbuildable state following a group of related checkins. It simply irks me no end, since it violates a lot of my precepts of professionalism. Yes, my suggested fix would put a build latency into the process of checkin. I am perfectly happy to hear other proposals for fixes that wouldn't. Meanwhile, if nothing else, we have bought 3-4 more months in which to address the problem or prepare for another session to get ourselves another 3-4 months after that... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 3 12:31:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA20483 for current-outgoing; Tue, 3 Sep 1996 12:31:05 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA20475 for ; Tue, 3 Sep 1996 12:30:59 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id OAA16538; Tue, 3 Sep 1996 14:29:29 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 14:29:30 -0500 To: Terry Lambert From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I think a more reasonable, one machine, version would be: > >1) wait some interval >2) copy active cvs tree to static cvs tree >3) test-build static cvs tree >4) if test-build fails, go to 1 >5) copy successfully test-built static cvs tree to distribution > cvs tree >6) people download distribution cvs tree > > >Posits: > >a) the interval in step 1 should be as short as step 3 allows >b) access to the distribution cvs tree should be blocked > during step 5; this could be implemented with a simple > access lock protocol obeyed by the copy process and the > download process(es) >c) we would prefer to block modification by programmers to > the active cvs tree during step 2 to ensure an increased > likelihood of buildability; a reader/writer lock would > provide a guarantee here -- note, again: the guarantee > is not necessary, only desirable >d) assuming locing protocols, it's possible to split the > process once per additional build machine, as a divisor > into the interval in step 1: this could reduce the overall > turnaround time between an active tree modification becoming > available I think we can use existing mechanisms in this scheme. A) Anyone who has the cvs tree can sync and extract what they wish at any time after a snapshot timestamp. A cookie service simply needs to notify them of the validated timestamps. Therefore replace "cvs tree" with "current tree" in the above discussion and use a validation timestamp distribution for step #5. B) Step #2, can be triggered either by serial number on the existing ctm distribution of the cvs tree or by free running "trial timestamp" generators. If you wish to apply locking, the trial timestamp generator would be the only mechanism that needs to participate. The advantage of this is that Condition (b) is handled by the servers locking out access while they apply the ctm update. The ctm generator for "current" is just a client of the timestamp service. When it receives a valid timestamp, it generates a new output. WRT "current", the servers can use the ctm distribution. I think that, in general, those updates would be faster than a new "checkout" of the entire tree. A side benefit is that someone could then use "sup" to get back in sync with ctm distributions. Condition (b) is handled by the servers locking out access while they apply the update. From owner-freebsd-current Tue Sep 3 13:31:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA23635 for current-outgoing; Tue, 3 Sep 1996 13:31:54 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA23626 for ; Tue, 3 Sep 1996 13:31:47 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA27094; Tue, 3 Sep 1996 13:31:14 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) by whistle.com via smap (V1.3) id sma027057; Tue Sep 3 13:31:09 1996 Message-ID: <322C9545.446B9B3D@whistle.com> Date: Tue, 03 Sep 1996 13:29:57 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.org CC: rkw@dataplex.net Subject: -current in production.. (was food for thought) References: <199609031919.MAA04862@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk With all the hullabaloo about -current not being stable or always building.. I thought I 'd give a little report here.. I sup the CVS tree at 2AM each day. I rebuild a system a couple of times a week. when it seems stable, I take a Snapshot of the sources, and the rest of the company moves onto that snapshot.. It's very rare that I have to abandon a snapshot because it doesn't build. I've really very happy with teh current scheme.. I think it's just expectations.. 1/ I sup the CVS tree so I get more control 2/ I have a sacrificial machine/environment I can test it on first.. I have -current (1 week old in about a dozen machines here. I'll be upgrading to yesterday's probably.. I have 4 in the field, and expect to have many more in a few months.. I think curretn has been quite stable.. If it fails, I just wait a day.. julian From owner-freebsd-current Tue Sep 3 13:51:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24666 for current-outgoing; Tue, 3 Sep 1996 13:51:52 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA24619 for ; Tue, 3 Sep 1996 13:50:47 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id WAA02874; Tue, 3 Sep 1996 22:30:24 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.5/8.7.3) with SMTP id WAA01060; Tue, 3 Sep 1996 22:07:31 +0200 (MET DST) Date: Tue, 3 Sep 1996 22:07:31 +0200 (MET DST) From: Andreas Klemm To: Frank Nobis cc: current@freebsd.org Subject: Re: is at(1) broken ? In-Reply-To: Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 3 Sep 1996, Frank Nobis wrote: > >>>>> "Andreas" == Andreas Klemm writes: > > Andreas> root{1008} ~ at 0830 /usr/libexec/uucp/uucico -r1 -x2 -Seasix Arghh ,,, yeah the command itself doesn't belong to the command line... Uh ... semms to be that I was a bit tired ?! ;-)) andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Tue Sep 3 13:53:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24753 for current-outgoing; Tue, 3 Sep 1996 13:53:21 -0700 (PDT) Received: from robin.mcnc.org (robin.mcnc.org [128.109.130.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA24746 for ; Tue, 3 Sep 1996 13:53:17 -0700 (PDT) Received: by robin.mcnc.org (8.6.9/MCNC/8-10-92) id QAA25476; Tue, 3 Sep 1996 16:53:06 -0400 for Date: Tue, 3 Sep 1996 16:53:06 -0400 From: "Frank E. Terhaar-Yonkers" Message-Id: <199609032053.QAA25476@robin.mcnc.org> To: current@freebsd.org Subject: suggestion: Re: Latest Current build failure X-Face: ,fjtWiMPydUaSQl%8[eTg`u:^BXt&T)Sny(6w\*U"5D9H[Z$kG%Q/z;Z=NwrPiXf-aMF3R) Rsand$,]26-8>5@HD(A3A79gN|0%NHsdek4mT8E,>j+\w!~d2#nH;~NV!5a0"`5$Cj8d\or(Jy/JQ_ |uc;C[filmZ(~#lre*l:|O%d/PJFy`.5w8)sMZ-)QI3TaV"j'k Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How about a simple status report? Like simply the CTM # and a one word status: "ng" (won't build), "builds" and "runs" (reasonably stable). One could then hold the CTM updates and only apply those up to a known stability point, waiting on those in-between. The field doesn't bleed so much, and current still gets a reasonable shake out. Snaps could be less frequent as well. - Frank Ollivier Robert Wrote: >To: current@freebsd.org >Subject: Re: Latest Current build failure > >According to Chuck Robey: >> I'm running ctm/cvs myself, and current has been incredibly stable. > >I don't want to add too much fuel to the discussion but I agree with Chuck >here. CURRENT is stable for me too. People who can't bear to have the tree >broken for a few hours without complaining should either stop running >CURRENT or provide a fix if they can't wait for the next sup/ctm. > >"Bleeding edge" has _bleeding_ in it. It seems that people tend to forget >that. I agree with Jordan that in an ideal world, it would be buildable at >any time but we live in a practical one; a few hic-hup are to be >expected. One should live with it or use only snapshots/releases... > >2 cts from a happy CURRENT user. >-- >Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr >FreeBSD keltia.freenix.fr 2.2-CURRENT #20: Fri Aug 30 23:00:02 MET DST 1996 > \\\\////\\\\////\\\\\////\\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\ Frank Terhaar-Yonkers, Manager High Performance Computing and Communications Research MCNC PO Box 12889 3021 Cornwallis Road Research Triangle Park, North Carolina 27709-2889 fty@mcnc.org voice (919)248-1417 FAX (919)248-1455 http://www.mcnc.org/hpcc.html From owner-freebsd-current Tue Sep 3 14:23:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA26148 for current-outgoing; Tue, 3 Sep 1996 14:23:02 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA26133 for ; Tue, 3 Sep 1996 14:22:51 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA05103; Tue, 3 Sep 1996 14:21:37 -0700 From: Terry Lambert Message-Id: <199609032121.OAA05103@phaeton.artisoft.com> Subject: Re: -current in production.. (was food for thought) To: julian@whistle.com (Julian Elischer) Date: Tue, 3 Sep 1996 14:21:37 -0700 (MST) Cc: current@FreeBSD.org, rkw@dataplex.net In-Reply-To: <322C9545.446B9B3D@whistle.com> from "Julian Elischer" at Sep 3, 96 01:29:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I thought I 'd give a little report here.. > > I sup the CVS tree at 2AM each day. > I rebuild a system a couple of times a week. > when it seems stable, I take a Snapshot of the sources, and the rest > of the company moves onto that snapshot.. > It's very rare that I have to abandon a snapshot because it doesn't > build. I've really very happy with teh current scheme.. I think it's > just expectations.. This is perfectly reasonable. The only problem is, people do not want to duplicate the stabilization work that you are already doing, they want it applied before the code goes into the downloadable tree. Alternately, they want a seperate downloadable tree (an unreasonable soloution, and the one everyone seems to be -- incorrectly -- focussing on, instead of backing up one level). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 3 16:14:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA02798 for current-outgoing; Tue, 3 Sep 1996 16:14:18 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA02793 for ; Tue, 3 Sep 1996 16:14:16 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id QAA10759; Tue, 3 Sep 1996 16:12:52 -0700 (PDT) To: Terry Lambert cc: michaelh@cet.co.jp, kimc@w8hd.org, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Tue, 03 Sep 1996 11:08:57 PDT." <199609031808.LAA04620@phaeton.artisoft.com> Date: Tue, 03 Sep 1996 16:12:51 -0700 Message-ID: <10757.841792371@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Why do you need more than one build box? Is it because the snapshot > from the tree is made on each download request instead of on a timed > copy of the tree? Yes, the unreliability of the Internet, if nothing else, virtually guarantees that perfect syncronization is impossible. By collecting multiple votes, it's more possible to determine the last time at which it's reasonable to assume the tree still worked. > I think a more reasonable, one machine, version would be: > > 1) wait some interval > 2) copy active cvs tree to static cvs tree > 3) test-build static cvs tree > 4) if test-build fails, go to 1 > 5) copy successfully test-built static cvs tree to distribution > cvs tree > 6) people download distribution cvs tree That's assuming that you want to make one box both the build and the central distribution server, and that machine definitely isn't freefall.freebsd.org. Finding a new central distribution server would be too much perturberation. Jordan From owner-freebsd-current Tue Sep 3 16:30:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA04127 for current-outgoing; Tue, 3 Sep 1996 16:30:51 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA04115 for ; Tue, 3 Sep 1996 16:30:46 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA05327; Tue, 3 Sep 1996 16:28:19 -0700 From: Terry Lambert Message-Id: <199609032328.QAA05327@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 3 Sep 1996 16:28:19 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, kimc@w8hd.org, current@FreeBSD.org In-Reply-To: <10757.841792371@time.cdrom.com> from "Jordan K. Hubbard" at Sep 3, 96 04:12:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I think a more reasonable, one machine, version would be: > > > > 1) wait some interval > > 2) copy active cvs tree to static cvs tree > > 3) test-build static cvs tree > > 4) if test-build fails, go to 1 > > 5) copy successfully test-built static cvs tree to distribution > > cvs tree > > 6) people download distribution cvs tree > > That's assuming that you want to make one box both the build and the > central distribution server, and that machine definitely isn't > freefall.freebsd.org. Finding a new central distribution server > would be too much perturberation. Actually, you could seperate the process using a covert channel for the checkout for the build server: 2) copy active cvs tree on repository to statis cvs tree on build server 5) copy successfully test-built static cvs tree on build server to distribution cvs tree on distribution server (could be the same machine, the repository, or could be a third machine) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 3 16:37:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA04589 for current-outgoing; Tue, 3 Sep 1996 16:37:37 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA04573 for ; Tue, 3 Sep 1996 16:37:34 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id QAA10862; Tue, 3 Sep 1996 16:36:39 -0700 (PDT) To: Terry Lambert cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Tue, 03 Sep 1996 12:02:35 PDT." <199609031902.MAA04818@phaeton.artisoft.com> Date: Tue, 03 Sep 1996 16:36:38 -0700 Message-ID: <10860.841793798@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > There are writer locks which you are not permitted to release until > a full build succeeds. But of course, that's shot down each time it > is brought up. Because it's essentially meaningless. A full build succeeds *where*, Terry? On the engineer's personal box? I can't count the number of build errors I've seen corrected with a sheepish "sorry guys, it worked on *my* box!" follow-up commit. Since engineers will always mess with their own boxes and the source tree still has far too many external dependencies to consider this a reasonable risk (down, Richard! :-), the distributed model can't work yet. That leaves one with the idea of doing it on a "build server" which is kept ideologically and morally pure, an increasingly hypothetical machine we're talking about here since it'd have to be fast enough to not become a choke-point and administered well enough that developers had various mechanisms available for "signing up" for the next build if one was already in progress. Not freefall, that's for sure. Anyway, the real answer is to fix the source tree and everyone here knows it. If one could build /usr/src completely "stand-alone" starting with a small reference-set of bootstrap binaries, and where these should come from or how they should be generated is a matter on which I'd welcome some debate, then a developer *could* check in changes after a certain degree of local testing and be far more assured that they'll work for everyone else. Jordan From owner-freebsd-current Tue Sep 3 17:41:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA11272 for current-outgoing; Tue, 3 Sep 1996 17:41:18 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA11263 for ; Tue, 3 Sep 1996 17:41:13 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA07717; Wed, 4 Sep 1996 00:40:51 GMT Date: Wed, 4 Sep 1996 09:40:51 +0900 (JST) From: Michael Hancock To: Richard Wackerbarth cc: "Jordan K. Hubbard" , current@FreeBSD.org Subject: Re: Food for thought In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 3 Sep 1996, Richard Wackerbarth wrote: > 1) Although I like the idea that "current" is readily available, forcing > new development to be done against it leads, IMHO, to making people use > something which is more unstable than what they need or desire. The > tradeoff is in the integration. It would be a disencentive for many developers if current didn't work this way. The solutions Jordan and Terry propose are in the right direction. Providing and making highly visible a buildable-current for the general public. Regards, Mike Hancock From owner-freebsd-current Tue Sep 3 18:09:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12433 for current-outgoing; Tue, 3 Sep 1996 18:09:57 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA12427 for ; Tue, 3 Sep 1996 18:09:52 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA24198 (5.65c/IDA-1.5 for ); Tue, 3 Sep 1996 18:08:23 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id UAA21271; Tue, 3 Sep 1996 20:05:56 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 20:05:56 -0500 To: Terry Lambert From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Actually, you could seperate the process using a covert channel for the >checkout for the build server: > >2) copy active cvs tree on repository to statis cvs tree on > build server >5) copy successfully test-built static cvs tree on build server > to distribution cvs tree on distribution server (could be > the same machine, the repository, or could be a third machine) As I have said, we don't need to worry about the distribution of "cvs" trees. If I have such a tree, I can check out the (redefined) "current" distribution without worrying whether or not it is the "head" or if "head" is buildable at the present time. What we need to "limit" is the access known as "current". Updates of that version would be subject to the "buildability" test. From owner-freebsd-current Tue Sep 3 18:13:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12546 for current-outgoing; Tue, 3 Sep 1996 18:13:26 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12537 for ; Tue, 3 Sep 1996 18:13:20 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id BAA07900; Wed, 4 Sep 1996 01:11:54 GMT Date: Wed, 4 Sep 1996 10:11:54 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: "Jordan K. Hubbard" , rkw@dataplex.net, current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <199609031902.MAA04818@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 3 Sep 1996, Terry Lambert wrote: > At Novell, using CVS with a reader/writer lock front end, we were > able to keep a project with 18+ engineers hacking on it 8-12 hours > a day buildable for every night but 5 for a period of 8 months. > Further, we did it on three machine architectures. With fulltime engineers in how many time zones? I previously thought this was a good idea when I first started supping current when current was going through a particularly unstable period. It isn't a good fit. FreeBSD which has volunteers working in multiple timezones. The current model is a good fit for this situation. The problem is that there isn't a good alternative to current for people who expect a buildable tree. The focus should be put on an automated way of providing a buildable tree and advertising it as the tree that most people should be downloading. Regards, Mike Hancock From owner-freebsd-current Tue Sep 3 18:13:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12569 for current-outgoing; Tue, 3 Sep 1996 18:13:30 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA12559 for ; Tue, 3 Sep 1996 18:13:28 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA24798 (5.65c/IDA-1.5 for ); Tue, 3 Sep 1996 18:11:59 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id UAA21280; Tue, 3 Sep 1996 20:09:02 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 20:09:01 -0500 To: Michael Smith From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Food for thought Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Richard Wackerbarth stands accused of saying: >> >> >Richard Wackerbarth stands accused of saying: >> >> >> >> 1) Although I like the idea that "current" is readily available, forcing >> >> new development to be done against it leads, IMHO, to making people use >> >> something which is more unstable than what they need or desire. The >> >> tradeoff is in the integration. >> > >> >Bollocks. -current is _incredibly_ stable for what is a running >> >second-by-second snapshot of a development tree in full swing. >> >> But many would be contributors have absolutely no need for such >> second-by-second access. They need a reasonably current platform against >> which they can do useful work. > >Which is what the -SNAP releases are for. Are you just being intentionally >dim or something? I thought at the start that you actually had some sort >of vaguely coherent idea of what you thought was the Right Way. So far >all you've done is whine about problems that don't actually exist. I disagree about the adequacy of "snap" releases. Jordan seems to get them out perhaps once a month. (I'm not faulting him) There are those who want to help check out things with much less latency, like maybe a day. The only problem is that they don't want to spend all of their time just getting the build to work. I think that Jordan is on the right track with his idea of an automated build "certification" scheme. If we implement such a scheme, it will soon become obvious whether the users are simply "whiners" or that they honestly have a beef. I propose that we divorce "current" from "head" in the sense that "current" becomes controlled snapshots of "head". Anyone who wants "head" MUST get it by cvs. To start, "current" would be "released" the 4 times per day that correspond to the ctm distribution of cvs. At each "release", a ctm-cur update would be generated. This would be the distribution method of choice for those who keep the entire tree and track it closely. (That includes, especially, the -current sup servers which would update in response to the release) As we find some willing machines, we can introduce a "certification" phase whereby the distribution is checked out and compiled. If it passes, notification is sent to release (or encourage the release) of a particular level of "current". Since the ctm-cur generator is the arbitrator of releases of "current", the policy would be implemented there. However, it would not be difficult to allow the reports to be generally distributed so that anyone with a cvs tree could make their own decision. From owner-freebsd-current Tue Sep 3 18:18:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12740 for current-outgoing; Tue, 3 Sep 1996 18:18:22 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12732 for ; Tue, 3 Sep 1996 18:18:19 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id BAA07941; Wed, 4 Sep 1996 01:17:08 GMT Date: Wed, 4 Sep 1996 10:17:08 +0900 (JST) From: Michael Hancock To: "Frank E. Terhaar-Yonkers" cc: current@FreeBSD.org Subject: Re: suggestion: Re: Latest Current build failure In-Reply-To: <199609032053.QAA25476@robin.mcnc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > How about a simple status report? Like simply the CTM # and a one It doesn't work. 3 hours later the status report is invalid. From owner-freebsd-current Tue Sep 3 18:29:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA13190 for current-outgoing; Tue, 3 Sep 1996 18:29:47 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA13172 for ; Tue, 3 Sep 1996 18:29:35 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA27579 (5.65c/IDA-1.5 for ); Tue, 3 Sep 1996 18:28:06 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id UAA21559; Tue, 3 Sep 1996 20:25:27 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 20:25:32 -0500 To: Michael Hancock From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Hancock writes: >The focus should be put on an automated way of providing a buildable tree >and advertising it as the tree that most people should be downloading. I agree! From owner-freebsd-current Tue Sep 3 19:04:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA15257 for current-outgoing; Tue, 3 Sep 1996 19:04:47 -0700 (PDT) Received: from VX23.CC.MONASH.EDU.AU (vx23.cc.monash.edu.au [130.194.1.23]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA15246 for ; Tue, 3 Sep 1996 19:04:41 -0700 (PDT) Received: from moa.cc.monash.edu.au (george@moa.cc.monash.edu.au) by vaxc.cc.monash.edu.au (PMDF V5.0-6 #16291) id <01I92W7CHXJI984THU@vaxc.cc.monash.edu.au> for current@FreeBSD.org; Wed, 04 Sep 1996 11:58:19 +1000 Received: (george@localhost) by moa.cc.monash.edu.au (8.6.10/8.6.4) id LAA05909 for current@FreeBSD.org; Wed, 04 Sep 1996 11:58:17 +1000 Date: Wed, 04 Sep 1996 11:58:17 +1000 From: George Scott Subject: Re: Latest Current build failure To: current@FreeBSD.org Message-id: <199609040158.LAA05909@moa.cc.monash.edu.au> Content-transfer-encoding: 7BIT Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Hell, the concept of "production level" doesn't even make sense when > discussing what's essentially a live snapshot of the engineering > team's working sources and, if anything, the real problem here is that > the WRONG PEOPLE are running -current! I think that part of the problem might be that the name is a little bit misleading. When I first started looking at FreeBSD and heard about CURRENT I had an image in my mind of the current release, ie, what I later discovered was called -RELEASE. A name like DEVEL might have been less confusing. I'm not suggesting that the name be changed, just trying to explain a phenomenon. Maybe the solution to the problem would be better advertising (ie, where -CURRENT is mentioned make it clear that it is development code). George. -- George Scott George.Scott@cc.monash.edu.au Systems Programmer, Caulfield Computer Centre, Monash University From owner-freebsd-current Tue Sep 3 20:47:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA18835 for current-outgoing; Tue, 3 Sep 1996 20:47:01 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA18828 for ; Tue, 3 Sep 1996 20:46:56 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id UAA14084; Tue, 3 Sep 1996 20:46:18 -0700 (PDT) Message-Id: <199609040346.UAA14084@austin.polstra.com> To: jkh@time.cdrom.com Cc: current@FreeBSD.org, sja@tekla.fi Subject: Re: Latest Current build failure Date: Tue, 03 Sep 1996 20:46:17 -0700 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Actually, all you'd need to do is have your cvsup file modified to > use a specific date in updating a previously checked out version > of HEAD. I think. John, would that work? :-) Yep, it sure would! Somewhere on my CVSup to-do list, though, is the ability to specify/override supfile settings on the command line and/or thru the GUI. That would be a lot more convenient than modifying your supfile every time. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Tue Sep 3 21:04:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA19518 for current-outgoing; Tue, 3 Sep 1996 21:04:19 -0700 (PDT) Received: from po8.andrew.cmu.edu (PO8.ANDREW.CMU.EDU [128.2.10.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA19507 for ; Tue, 3 Sep 1996 21:04:16 -0700 (PDT) Received: (from postman@localhost) by po8.andrew.cmu.edu (8.7.5/8.7.3) id AAA27263 for freebsd-current@freefall.FreeBSD.org; Wed, 4 Sep 1996 00:04:13 -0400 Received: via switchmail; Wed, 4 Sep 1996 00:04:12 -0400 (EDT) Received: from unix18.andrew.cmu.edu via qmail ID ; Wed, 4 Sep 1996 00:03:58 -0400 (EDT) Received: from unix18.andrew.cmu.edu via qmail ID ; Wed, 4 Sep 1996 00:03:57 -0400 (EDT) Received: from VUI.Andrew.3.70.CUILIB.3.45.SNAP.NOT.LINKED.unix18.andrew.cmu.edu.sun4x.55 via MS.5.6.unix18.andrew.cmu.edu.sun4_51; Wed, 4 Sep 1996 00:03:57 -0400 (EDT) Message-ID: Date: Wed, 4 Sep 1996 00:03:57 -0400 (EDT) From: Tao Jiang To: freebsd-current@freefall.FreeBSD.org Subject: How to set up dynamic ip ppp or slip connection? Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, can some one tell me step by step how I can set up my freebsd 2.2 system to connect to my school which assign dynamic ip address to me? From owner-freebsd-current Tue Sep 3 21:16:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA20100 for current-outgoing; Tue, 3 Sep 1996 21:16:54 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA20095 for ; Tue, 3 Sep 1996 21:16:52 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id VAA00620; Tue, 3 Sep 1996 21:16:31 -0700 (PDT) To: rkw@dataplex.net (Richard Wackerbarth) cc: Michael Smith , current@freebsd.org Subject: Re: Food for thought In-reply-to: Your message of "Tue, 03 Sep 1996 20:09:01 CDT." Date: Tue, 03 Sep 1996 21:16:31 -0700 Message-ID: <618.841810591@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Anyone who wants "head" MUST get it by cvs. Ah, and if only Hugh Grant had heeded this sage advice! :-) Jordan From owner-freebsd-current Tue Sep 3 21:25:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA20540 for current-outgoing; Tue, 3 Sep 1996 21:25:55 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA20535 for ; Tue, 3 Sep 1996 21:25:53 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA03285; Wed, 4 Sep 1996 13:55:34 +0930 From: Michael Smith Message-Id: <199609040425.NAA03285@genesis.atrad.adelaide.edu.au> Subject: Re: Food for thought To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 4 Sep 1996 13:55:34 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, current@freebsd.org In-Reply-To: from "Richard Wackerbarth" at Sep 3, 96 08:09:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth stands accused of saying: > > I disagree about the adequacy of "snap" releases. Jordan seems to get them > out perhaps once a month. (I'm not faulting him) There are those who want > to help check out things with much less latency, like maybe a day. The only > problem is that they don't want to spend all of their time just getting the > build to work. You are totally beyond reason, I'm afraid. You want stuff to be "stable", but you expect the whole testing process to produce a lag of less than a _day_? What sort of billion-dollar empire do you think FreeBSD inc. is?? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Tue Sep 3 21:35:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA21012 for current-outgoing; Tue, 3 Sep 1996 21:35:08 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA21005 for ; Tue, 3 Sep 1996 21:35:06 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id VAA00700; Tue, 3 Sep 1996 21:34:14 -0700 (PDT) To: John Polstra cc: current@FreeBSD.org, sja@tekla.fi Subject: Re: Latest Current build failure In-reply-to: Your message of "Tue, 03 Sep 1996 20:46:17 PDT." <199609040346.UAA14084@austin.polstra.com> Date: Tue, 03 Sep 1996 21:34:14 -0700 Message-ID: <697.841811654@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Somewhere on my CVSup to-do list, though, is the ability to > specify/override supfile settings on the command line and/or thru > the GUI. That would be a lot more convenient than modifying your > supfile every time. Definitely - coolness! Make it powerful enough to accept just about everything on the command line and you make it a lot more straight-forward to drive it externally (perhaps from some nice drag-and-drop collection selector) without temp files. Terry, of course, would request that cvsup ask an external data abstraction layer for all its resource information, allowing one to say things like: % cvsup -release=cvs -host=cvsup.freebsd.org -hostbase=/home \ -base=/usr -prefix=/home/ncvs -options delete,old \ -coll=src-bin -coll=src-contrib -coll=ports-all or % cvsup cvsup> set release cvs cvsup> set host cvsup.freebsd.org cvsup> cvsup> commit cvsup> quit Or even drive it through an expanded version of the current GUI, somehow. Whether or not you actually choose to go to that level of complexity is entirely your choice, of course. :-) Despite the fact that I seem to be poking fun at it, I'm also in agreement with Terry that allowing a tool to be "driven" as generically as possible is a good thing, I'm just still waiting for someone to contribute a "command and resource driver" library which makes it easy to instrument new and existing applications in this way without substantially reinventing the wheel for each and every one. Something modelled after the X Toolkit's resource mechanism with some command-line parsing/dispatching code thrown in would be a good start, though some might also argue that this is already being done by a library called libtcl.a. :-) Jordan From owner-freebsd-current Tue Sep 3 21:46:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA21507 for current-outgoing; Tue, 3 Sep 1996 21:46:00 -0700 (PDT) Received: from freenet.hamilton.on.ca (main.freenet.hamilton.on.ca [199.212.94.65]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA21501 for ; Tue, 3 Sep 1996 21:45:58 -0700 (PDT) From: hoek@freenet.hamilton.on.ca Received: from james.freenet.hamilton.on.ca (james.freenet.hamilton.on.ca [199.212.94.66]) by freenet.hamilton.on.ca (8.7.5/8.7.3) with ESMTP id AAA03244; Wed, 4 Sep 1996 00:46:02 -0400 (EDT) Received: (from ac199@localhost) by james.freenet.hamilton.on.ca (8.7.5/8.7.3) id AAA17307; Wed, 4 Sep 1996 00:47:46 -0400 (EDT) Date: Wed, 4 Sep 1996 00:47:46 -0400 (EDT) Message-Id: <199609040447.AAA17307@james.freenet.hamilton.on.ca> X-Mailer: slnr v.2.13 as ported to FreeBSD To: jkh@time.cdrom.com Cc: current@freebsd.org Subject: Re: Latest Current build failure Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In Email, "Jordan K. Hubbard" wrote: > > If you've achieved nothing else, you've definitely made the point to > me that we've got a serious image problem with -current these days, > namely that it's entirely *too* visible. -current was truly never That's because you called it -current instead of something like -experimental.... "current" is a word usually associated with generally good things... "current" technology, "current" affairs... The "current" version of most commercial software is the last version _released_, not the version being developed. -experimental, or -develop is a much more apt description. It's semantics at its worst. -- -- tIM...HOEk The opinions expressed above are mine, and if my employer shares them, that's his hard luck. From owner-freebsd-current Tue Sep 3 23:01:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA24665 for current-outgoing; Tue, 3 Sep 1996 23:01:40 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA24660 for ; Tue, 3 Sep 1996 23:01:36 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id LAA25008; Tue, 3 Sep 1996 11:26:45 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Tue, 3 Sep 96 11:26 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.7.5/8.7.5) id LAA14818; Tue, 3 Sep 1996 11:26:44 -0500 (CDT) From: Karl Denninger Message-Id: <199609031626.LAA14818@Jupiter.mcs.net> Subject: Re: Food for thought To: imp@village.org (Warner Losh) Date: Tue, 3 Sep 1996 11:26:44 -0500 (CDT) Cc: current@FreeBSD.org In-Reply-To: <199609031549.JAA26803@rover.village.org> from "Warner Losh" at Sep 3, 96 09:49:53 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > CVS tree takes an extra 250M of hard disk. That's still $50 worth of > hard disk, but you have to buy it in $200-$300 chunks, which can be > hard for people. Or run the risk of the used market... > > That said, I recently bought more disk (a Jaz drive), and have been > very happy with CTM of CVS. I've not had any make worlds fail since > I've moved over to that which weren't the result of disk full > failures. > > If you are going to play the -current game, you need at least 2.0G of > disk available. 700M for CVS + source + obj and 1.3 to do your real > work on :-) IMHO, of course. > > One thing I really *LIKE* about OpenBSD's anoncvs is that you can grab > a *SUBSET* of the tree and not have to pay the price of having both > the CVS tree and the whole source tree online. If someone were really > upset about the current build situation, purhaps their energies might > be better spent setting up an experimental anoncvs server fed off a > ctm maintained CVS tree so that the FreeBSD community might benefit > from that. > > Just some random thoughts... > > Warner A full build tree for FreeBSD + the Ports collection requires approximately 8G of space, including the working set of files and enough room for a "make release". If you're building systems which you wish to be able to distribute files for (ie: you have a custom environment and want local repositories for all of it) this is what you need as of today. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-current Wed Sep 4 00:06:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA28832 for current-outgoing; Wed, 4 Sep 1996 00:06:08 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA28825; Wed, 4 Sep 1996 00:06:05 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id IAA08054; Wed, 4 Sep 1996 08:25:28 +0200 (MET DST) To: "Frank E. Terhaar-Yonkers" cc: current@freebsd.org Subject: Re: suggestion: Re: Latest Current build failure In-reply-to: Your message of "Tue, 03 Sep 1996 16:53:06 EDT." <199609032053.QAA25476@robin.mcnc.org> Date: Wed, 04 Sep 1996 08:25:28 +0200 Message-ID: <8052.841818328@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609032053.QAA25476@robin.mcnc.org>, "Frank E. Terhaar-Yonkers" w rites: > >How about a simple status report? Like simply the CTM # and a one >word status: "ng" (won't build), "builds" and "runs" (reasonably stable). >One could then hold the CTM updates and only apply those up to a known >stability point, waiting on those in-between. The field doesn't bleed >so much, and current still gets a reasonable shake out. This is what you, dear hacker, needs to decide for yourself by reading the committers list. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Wed Sep 4 01:24:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA01412 for current-outgoing; Wed, 4 Sep 1996 01:24:18 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA01407 for ; Wed, 4 Sep 1996 01:24:14 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.7.5/8.6.9) with SMTP id JAA01003; Wed, 4 Sep 1996 09:24:10 +0100 (BST) Date: Wed, 4 Sep 1996 09:24:10 +0100 (BST) From: Developer To: Julian Elischer cc: freebsd-current@freebsd.org Subject: Re: HELP URGENT!!! In-Reply-To: <322C818E.167EB0E7@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 3 Sep 1996, Julian Elischer wrote: > > Can't open /dev/rsd2a Device not configured. > > > > In /var/log/messages there is this error:- > > > > /kernel: sd2: Can't deal with 767 bytes logical blocks > this message doesn't come from the label, but from the disk driver > when it asks the drive how it is formatted.. > /* > * Load the physical device parameters > */ > sd_get_parms(unit, 0); /* sets SDEV_MEDIA_LOADED */ > if (sd->params.secsiz != SECSIZE) { /* XXX One day... */ > printf("sd%ld: Can't deal with %d bytes logical > blocks\n", > unit, sd->params.secsiz); > Debugger("sd"); > > here is the debugger call.. the original intention is to let you > examine the results from the sd_get_params call > errcode = ENXIO; > goto bad; > } > > Your disk has been "partially reformetted" > OR > it's gone crazy > OR > sd_get_parms(unit,0) > is returning garbage (probably also due to a mad disk) > > > > > Seems like the disklabel is dodgy :( > > nope.. see above.. > > > > > Any ideas how to fix it? It's desperate?? > > compile a kernel with the SCSIDEBUG > then after booting do: > scsi -d 15 -f /dev/rsd2.ctl > this will turn on TONS of debugging > if it's too much -d 1 might be better > > this should give you the results of all operations affecting > that device... > > julian > in the mean-while > don't write to that device (not that it'll let you :) Thanks for all your help:) The strange thing is when we rebooted the machine again this morning it booted up just fine!! I wonder if it could be a hardware error? Regards, Trefor S. From owner-freebsd-current Wed Sep 4 02:09:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA02766 for current-outgoing; Wed, 4 Sep 1996 02:09:11 -0700 (PDT) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA02760 for ; Wed, 4 Sep 1996 02:09:08 -0700 (PDT) Received: (from obrien@localhost) by relay.nuxi.com (8.7.5/8.6.12) id CAA11993; Wed, 4 Sep 1996 02:09:08 -0700 (PDT) Message-Id: <199609040909.CAA11993@relay.nuxi.com> Date: Wed, 4 Sep 1996 02:09:07 -0700 From: obrien@Nuxi.cs.ucdavis.edu (David E. O'Brien) To: current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <199609040447.AAA17307@james.freenet.hamilton.on.ca>; from hoek@freenet.hamilton.on.ca on Sep 4, 1996 0:47:46 -0400 References: <199609040447.AAA17307@james.freenet.hamilton.on.ca> X-Mailer: Mutt 0.41 Mime-Version: 1.0 X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hoek@freenet.hamilton.on.ca writes: > In Email, "Jordan K. Hubbard" wrote: > > > > If you've achieved nothing else, you've definitely made the point to > > me that we've got a serious image problem with -current these days, > > namely that it's entirely *too* visible. -current was truly never > > That's because you called it -current instead of something like > -experimental.... "current" is a word usually associated with generally > good things... "current" technology, "current" affairs... The "current" You've also got the problem that -current has evolved substantually beyond -release. At one time, -current was the way future of FBSD, full of "experiements". But, if you read the newsgroup/lists it quickly becomes appartent that in order to contribute hardly at all you need to be running -current. Often I've seen people wanting to try to get involved, and are told that they should submit diffs agaist -current because -current is too differnt from -release and the integration effort is too much. The requirement to be running -current has even crept into porting. With the latest changes (moving of libs from /usr/ports to /usr/lib for example), not even that form of contribution hasn't been touched. -- David (obrien@cs.ucdavis.edu) From owner-freebsd-current Wed Sep 4 02:20:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA03047 for current-outgoing; Wed, 4 Sep 1996 02:20:33 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA03010 for ; Wed, 4 Sep 1996 02:19:25 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA15326; Wed, 4 Sep 1996 11:15:37 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA19302; Wed, 4 Sep 1996 11:15:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA00541; Wed, 4 Sep 1996 10:51:20 +0200 (MET DST) From: J Wunsch Message-Id: <199609040851.KAA00541@uriah.heep.sax.de> Subject: Re: HELP URGENT!!! To: julian@whistle.com (Julian Elischer) Date: Wed, 4 Sep 1996 10:51:20 +0200 (MET DST) Cc: dev@fgate.flevel.co.uk, freebsd-current@freebsd.org In-Reply-To: <322C818E.167EB0E7@whistle.com> from Julian Elischer at "Sep 3, 96 12:05:50 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Elischer wrote: > > Debugger("sd") > > Stopped at _Debugger+0x26: movb $0,_in_Debugger.116 > > db> > this message doesn't come from the label, but from the disk driver > when it asks the drive how it is formatted.. > if (sd->params.secsiz != SECSIZE) { /* XXX One day... */ > printf("sd%ld: Can't deal with %d bytes logical > blocks\n", > unit, sd->params.secsiz); > Debugger("sd"); This should become a panic() with a more explanatory message. Direct calls to Debugger() should not get directly into the code. They can only be found in a few places at all, the SCSI subsystem parts are the biggest offenders. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Sep 4 03:31:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA05397 for current-outgoing; Wed, 4 Sep 1996 03:31:31 -0700 (PDT) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA05392 for ; Wed, 4 Sep 1996 03:31:25 -0700 (PDT) Received: (from uucp@localhost) by perki0.connect.com.au id UAA22736 (8.7.5/IDA-1.6); Wed, 4 Sep 1996 20:31:03 +1000 (EST) >Received: from localhost (localhost [127.0.0.1]) by nemeton.com.au (8.7.5/8.7.3) with SMTP id UAA28175; Wed, 4 Sep 1996 20:08:14 +1000 (EST) Message-Id: <199609041008.UAA28175@nemeton.com.au> To: "Frank E. Terhaar-Yonkers" cc: current@freebsd.org Subject: Re: suggestion: Re: Latest Current build failure In-reply-to: <199609032053.QAA25476@robin.mcnc.org> Date: Wed, 04 Sep 1996 20:08:14 +1000 From: Giles Lean Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 3 Sep 1996 16:53:06 -0400 "Frank E. Terhaar-Yonkers" wrote: > How about a simple status report? Like simply the CTM # and a one > word status: "ng" (won't build), "builds" and "runs" (reasonably > stable). I'm working on this. I presently think the test for OK should be just that 'make world' ran OK and then a newly built kernel could be booted. This much is easy to automate. Following another posting I guess that if 'make world' fails it should be retried after 'make bootstrap'. Thoughts, anyone? Judging "stable" is rather more difficult for a dumb shell script. :-) Giles From owner-freebsd-current Wed Sep 4 05:42:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA09163 for current-outgoing; Wed, 4 Sep 1996 05:42:35 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-18-163.pt.uk.ibm.net [139.92.18.163]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA09150; Wed, 4 Sep 1996 05:42:27 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id LAA00901; Wed, 4 Sep 1996 11:19:10 +0200 (MET DST) Message-Id: <199609040919.LAA00901@vector.jhs.no_domain> To: "Jordan K. Hubbard" cc: current@FreeBSD.org Subject: Re: Latest Current build failure From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Tue, 03 Sep 1996 05:10:28 PDT." <9251.841752628@time.cdrom.com> Date: Wed, 04 Sep 1996 11:19:10 +0200 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Reference: > From: "Jordan K. Hubbard" > warrantee given or implied! Extremely slippery when wet!" and we ... > strongly and openly dissuaded from so doing in the Handbook's section Those who get as far as finding the Handbook probably don't ask the daftest questions, in general :-) Jordan, I suggest you shrink your posting, & create a src/README with it, to define what {current, stable, snap, release} all are, & what is expected of the sources _and_ the users. So we can in good conscience cry `RTFM', the README should have URLs : ------ Handbook
  • Web site www.freebsd.org
  • Installed /usr/share/doc/handbook/handbook.html
  • Object tree /usr/obj/usr/src/share/doc/handbook/handbook.html
  • Sgml source: /usr/src/share/doc/handbook/handbook.sgml
  • Frequently Answered Questions
  • Web site www.freebsd.org
  • Installed /usr/share/doc/FAQ/freebsd-faq.html
  • Object tree /usr/obj/usr/src/share/doc/FAQ/freebsd-faq.html
  • Sgml source: /usr/src/share/doc/FAQ/freebsd-faq.sgml
    • ------ Almost every piece of free software has a README to get one started ... FreeBSD in src/ does not, currently, its a missing link we could easily fill. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Wed Sep 4 05:43:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA09199 for current-outgoing; Wed, 4 Sep 1996 05:43:02 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-18-163.pt.uk.ibm.net [139.92.18.163]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA09188; Wed, 4 Sep 1996 05:42:54 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id KAA00846; Wed, 4 Sep 1996 10:54:11 +0200 (MET DST) Message-Id: <199609040854.KAA00846@vector.jhs.no_domain> To: rkw@dataplex.net (Richard Wackerbarth) cc: gjennejohn@frt.dec.com, current@FreeBSD.org Subject: Re: Latest Current build failure From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Tue, 03 Sep 1996 06:56:44 CDT." Date: Wed, 04 Sep 1996 10:54:10 +0200 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: rkw@dataplex.net (Richard Wackerbarth) > Subject: Re: Latest Current build failure > Date: Tue, 3 Sep 1996 06:56:44 -0500 > Message-id: > > dropped. CVSup of the total tree is appropriate for the "bleeding > edger's". But CVSup is not the only appropriate solution ... We've had developers who produced useful code but were doomed to bad coms links. CTM is asynchronous to net disturbances, so ideal for those with poor net access, whereas cvsup requires a net in good condition. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Wed Sep 4 05:43:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA09227 for current-outgoing; Wed, 4 Sep 1996 05:43:17 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-18-163.pt.uk.ibm.net [139.92.18.163]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA09209; Wed, 4 Sep 1996 05:43:05 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id KAA00828; Wed, 4 Sep 1996 10:49:12 +0200 (MET DST) Message-Id: <199609040849.KAA00828@vector.jhs.no_domain> To: sja@tekla.fi (Sakari Jalovaara) cc: current@FreeBSD.org Subject: Re: Latest Current build failure From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Tue, 03 Sep 1996 11:27:34 +0300." <9609030827.AA05232@tahma.tekla.fi> Date: Wed, 04 Sep 1996 10:49:11 +0200 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: sja@tekla.fi (Sakari Jalovaara) > Subject: Re: Latest Current build failure > Date: Tue, 3 Sep 1996 11:27:34 +0300 > Message-id: <9609030827.AA05232@tahma.tekla.fi> > > How about this idea: > > Everyone cvsups the bleeding edge RCS files. NO ! That assumes everyone has good net connectivity ... & they don't all. CTM has distinct advantages for maintenance of my local CVS tree, namely, only my local ISP needs be up to supply the mail, even if the rest of the net, or freebsd servers are dead or slow as hell... no problem ! > (Have mercy on me if this is totally silly - I'm new to FreeBSD and > I'm not even using current - yet.) .... Grin .... No Comment ;-) Don't confuse the various methods of distributing updates {sup mirror ctm cvsup } with the method of src/ tree maintenace { cvs extract on dates or head, current/, stable/ snaps etc ) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Wed Sep 4 05:46:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA09458 for current-outgoing; Wed, 4 Sep 1996 05:46:24 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA09446 for ; Wed, 4 Sep 1996 05:46:20 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.7.5/8.6.9) with SMTP id NAA07430 for ; Wed, 4 Sep 1996 13:46:40 +0100 (BST) Date: Wed, 4 Sep 1996 13:46:40 +0100 (BST) From: Developer To: freebsd-current@freebsd.org Subject: FXHTML - An extension to HTML now available for FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Announcement ------------ Fourth Level Developments have recently released a their new extension to HTML which allows users to write programs, which would normally require complex cgi scripts (Usually written in perl and Java), using familiar and easy to use HTML style tags. FXHTML handles the complexities of collecting data from forms and dynamically generating your web pages using commands which are familiar and easy to learn. FXHTML is installed onto your web server and is transparent to the end user. If you are interested in finding out more information about FXHTML then please look at: http://www.flevel.co.uk/fxhtml/ or email: dev@flevel.co.uk From owner-freebsd-current Wed Sep 4 07:23:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA13564 for current-outgoing; Wed, 4 Sep 1996 07:23:39 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA13558 for ; Wed, 4 Sep 1996 07:23:35 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id HAA17141; Wed, 4 Sep 1996 07:21:59 -0700 (PDT) Message-Id: <199609041421.HAA17141@austin.polstra.com> To: jkh@time.cdrom.com Cc: current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: <199609040346.UAA14084@austin.polstra.com> Date: Wed, 04 Sep 1996 07:21:59 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Terry, of course, would request that cvsup ask an external data > abstraction layer for all its resource information ... > Whether or not you actually choose to go to that level of complexity > is entirely your choice, of course. :-) Whatever. Just so long as I get to use the word "meta-configuration" at least once in the manual page. ;-) John From owner-freebsd-current Wed Sep 4 07:35:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14129 for current-outgoing; Wed, 4 Sep 1996 07:35:14 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14123; Wed, 4 Sep 1996 07:35:11 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id IAA02549; Wed, 4 Sep 1996 08:35:09 -0600 (MDT) Message-Id: <199609041435.IAA02549@rover.village.org> To: "Julian H. Stacey" Subject: Re: Latest Current build failure Cc: current@FreeBSD.org In-reply-to: Your message of Wed, 04 Sep 1996 10:54:10 +0200 Date: Wed, 04 Sep 1996 08:35:08 -0600 From: Warner Losh Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : We've had developers who produced useful code but were doomed to bad coms : links. CTM is asynchronous to net disturbances, so ideal for those with : poor net access, whereas cvsup requires a net in good condition. And CTM happens async to my desires. If I go out of town for a week, it will happily (and correctly to my way of thinking) keep updating the whole time I'm gone. I don't have to suck my link down for 6hr and pray a lot if that is the week that gcc 2.8, perl 6 and tcl 12.3 were committed... I have plenty of mail spool space :-) Warner From owner-freebsd-current Wed Sep 4 08:20:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA16690 for current-outgoing; Wed, 4 Sep 1996 08:20:02 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA16653; Wed, 4 Sep 1996 08:19:58 -0700 (PDT) Message-Id: <199609041519.IAA16653@freefall.freebsd.org> To: "Julian H. Stacey" cc: rkw@dataplex.net (Richard Wackerbarth), gjennejohn@frt.dec.com, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 10:54:10 +0200." <199609040854.KAA00846@vector.jhs.no_domain> Date: Wed, 04 Sep 1996 08:19:58 -0700 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >But CVSup is not the only appropriate solution ... >We've had developers who produced useful code but were doomed to bad coms >links. CTM is asynchronous to net disturbances, so ideal for those with >poor net access, whereas cvsup requires a net in good condition. This isn't true since CVSup is a streaming protocol instead of a synchronous like SUP. I know quite a few people who switched from CTM to CVSup that have poor links to the net. >Julian >-- >Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 4 08:51:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA17971 for current-outgoing; Wed, 4 Sep 1996 08:51:46 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA17965 for ; Wed, 4 Sep 1996 08:51:41 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 04 Sep 1996 09:51:44 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 04 Sep 1996 09:59:36 -0600 From: Darren Davis To: michaelh@cet.co.jp, terry@lambert.org Cc: rkw@dataplex.net, current@freebsd.org, jkh@time.cdrom.com Subject: Re: Latest Current build failure - Reply Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> Michael Hancock 9/ 3 7:11pm >>> >On Tue, 3 Sep 1996, Terry Lambert wrote: > >> At Novell, using CVS with a reader/writer lock front end, we were >> able to keep a project with 18+ engineers hacking on it 8-12 hours >> a day buildable for every night but 5 for a period of 8 months. >> Further, we did it on three machine architectures. > >With fulltime engineers in how many time zones? We have fulltime engineers in San Jose CA, Provo UT, and India. We used to have a bunch of engineers in Summit NJ, but not to many anymore. All these timezones are still working on the source tree that Terry is talking about. Darren R. Davis Senior Software Engineer Novell, Inc. From owner-freebsd-current Wed Sep 4 09:07:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA18662 for current-outgoing; Wed, 4 Sep 1996 09:07:42 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA18657 for ; Wed, 4 Sep 1996 09:07:41 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 04 Sep 1996 10:07:55 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 04 Sep 1996 10:15:41 -0600 From: Darren Davis To: jkh@time.cdrom.com Cc: msmith@atrad.adelaide.edu.au, current@freebsd.org Subject: Re: Food for thought - Reply Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ROTFL ;-) Darren >>> "Jordan K. Hubbard" 9/ 3 10:16pm >>> > Anyone who wants "head" MUST get it by cvs. Ah, and if only Hugh Grant had heeded this sage advice! :-) Jordan From owner-freebsd-current Wed Sep 4 09:38:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA20037 for current-outgoing; Wed, 4 Sep 1996 09:38:52 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA20031 for ; Wed, 4 Sep 1996 09:38:48 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA06605; Wed, 4 Sep 1996 09:34:54 -0700 From: Terry Lambert Message-Id: <199609041634.JAA06605@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 09:34:54 -0700 (MST) Cc: terry@lambert.org, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <10860.841793798@time.cdrom.com> from "Jordan K. Hubbard" at Sep 3, 96 04:36:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > There are writer locks which you are not permitted to release until > > a full build succeeds. But of course, that's shot down each time it > > is brought up. > > Because it's essentially meaningless. A full build succeeds *where*, > Terry? On the engineer's personal box? I can't count the number of > build errors I've seen corrected with a sheepish "sorry guys, it > worked on *my* box!" follow-up commit. A full build succeeds on a checked out source tree with a limited path relatively pointed into the build area, of course. In effect, this would mean that there was no difference in the engineers build environment and that of anyone who checked out the code at any lock release time stamp. This assumes that the writer lock is held over the build process; if it were a nightly build run by cron on another box, then it would work as well as the engineer's personal box. Of course, we used the full feature set of CVS between time synced NFS mounted boxes, so any hodge-podge environment less than that would not perform quite as well. However, the problem is one of not putting up crap for general download, and it can be solved by only putting a newer version up after a successful build, rather than establishing an integrated developement environment. There are many paths to the same results. The benefit here is that the person doing the checkin will not get his bits on his next tree synchronization until his bit work. Kind of a dual incentive. > Since engineers will always > mess with their own boxes and the source tree still has far too many > external dependencies to consider this a reasonable risk (down, > Richard! :-), the distributed model can't work yet. Actually, "Go, Richard!... Richard! - Richard! - Richard!". > That leaves one with the idea of doing it on a "build server" which > is kept ideologically and morally pure, an increasingly hypothetical > machine we're talking about here since it'd have to be fast enough to > not become a choke-point and administered well enough that developers > had various mechanisms available for "signing up" for the next build > if one was already in progress. Not freefall, that's for sure. Adding latency is not the same thing as adding a "choke-point"; the only increasingly hypothetical thing here is the idea that a broken source tree is less of a barrier to progress than an increased latency for change availability. And you're right, Freefall would be a bad choice for the build machine... it has too much additional software installed such that new dependencies would not be immediately obvious. Look at the "shared lib Motif XEmacs" port problem that sneaked through: a result of too much installed software on the ports machine. Or if we believe Richard (and I happen to believe him), a result of failed segregation of host/build environments. > Anyway, the real answer is to fix the source tree and everyone here > knows it. If one could build /usr/src completely "stand-alone" > starting with a small reference-set of bootstrap binaries, and where > these should come from or how they should be generated is a matter on > which I'd welcome some debate, then a developer *could* check in > changes after a certain degree of local testing and be far more > assured that they'll work for everyone else. This will help in the external dependencies case, but it won't help in the "agregate changes fail to compile" case -- which seems to be the most frequent problem area. I think the most frequent problem area remains unaddressed, even in a fixed source tree. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 09:58:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA20854 for current-outgoing; Wed, 4 Sep 1996 09:58:40 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA20847; Wed, 4 Sep 1996 09:58:34 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id JAA18063; Wed, 4 Sep 1996 09:58:31 -0700 (PDT) Message-Id: <199609041658.JAA18063@austin.polstra.com> To: jhs@FreeBSD.org Cc: current@FreeBSD.org, gibbs@freefall.freebsd.org Subject: Re: Latest Current build failure In-reply-to: <199609041519.IAA16653@freefall.freebsd.org> Date: Wed, 04 Sep 1996 09:58:30 -0700 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Julian Stacey : > >CTM is asynchronous to net disturbances, so ideal for those with > >poor net access, whereas cvsup requires a net in good condition. Justin Gibbs : > This isn't true since CVSup is a streaming protocol instead of a > synchronous like SUP. I know quite a few people who switched from > CTM to CVSup that have poor links to the net. Justin is right. CVSup works very well under poor network conditions. That was one of the primary design goals. In fact, CVSup almost certainly works better under adverse conditions than SMTP, which delivers your CTM updates. Julian, have you even _tried_ CVSup?? I watch the server logs pretty closely, and I don't recall seeing your name in them. It's not in anybody's interest to start a "CVSup vs. CTM" war. They each have advantages and disadvantages. People are welcome to use the one that serves their needs the best. (Sup, on the other hand, can die die die, as far as I'm concerned. ;-) But if you're going to comment publically on either CVSup or CTM, you really ought to know what you're talking about first. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Wed Sep 4 10:14:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA21510 for current-outgoing; Wed, 4 Sep 1996 10:14:14 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA21505 for ; Wed, 4 Sep 1996 10:14:07 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id KAA18153; Wed, 4 Sep 1996 10:13:56 -0700 (PDT) Message-Id: <199609041713.KAA18153@austin.polstra.com> To: jkh@time.cdrom.com Cc: current@FreeBSD.org, sja@tekla.fi Subject: Re: Latest Current build failure In-reply-to: <199609040346.UAA14084@austin.polstra.com> Date: Wed, 04 Sep 1996 10:13:55 -0700 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I was thinking some more about an idea Jordan brought up: > Actually, all you'd need to do is have your cvsup file modified to > use a specific date in updating a previously checked out version > of HEAD. Here is a related idea I've been toying with. I think I could easily extend CVSup to support "pseudo-tags". These would be like CVS tags, except they wouldn't really exist in the repository. Instead, the CVSup server would know about them. A pseudo-tag would correspond to some date on some branch. The user could request an update for a pseudo-tag exactly as he now gets an update for a real tag. There could be a pseudo-tag called, say, RELENG_2_2_RECENT, representing the almost-current, more-likely-buildable version. I.e., it would refer to the main branch at some cutoff date specified on the server. The cutoff date could be read from a configuration file on the server. Whenever a newer version of -current was deemed to be good/stable enough, the date would be updated in the server configuration file. The user would always specify the same tag; it would mean whatever the people who administered the server wanted it to mean. That seems better than asking the users to change their cutoff dates all the time. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Wed Sep 4 10:22:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA21958 for current-outgoing; Wed, 4 Sep 1996 10:22:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA21948 for ; Wed, 4 Sep 1996 10:22:45 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA06682; Wed, 4 Sep 1996 10:13:19 -0700 From: Terry Lambert Message-Id: <199609041713.KAA06682@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 4 Sep 1996 10:13:19 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, rkw@dataplex.net, current@freebsd.org In-Reply-To: from "Michael Hancock" at Sep 4, 96 10:11:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > At Novell, using CVS with a reader/writer lock front end, we were > > able to keep a project with 18+ engineers hacking on it 8-12 hours > > a day buildable for every night but 5 for a period of 8 months. > > Further, we did it on three machine architectures. > > With fulltime engineers in how many time zones? Three. Utah (MST), Texas (CST), and New Jersey (PST). We also had two engineers on GMT (England), but they worked by rlogin into the New Jersey site (transatlantic timesync was a problem). Further, the CVS tree was NFS mounted on the engineers boxes, and they were timesynced to the NFS server's clock. If you don't NFS mount the CVS tree, the timesync/rlogin problem goes away. > FreeBSD which has volunteers working in multiple timezones. The current > model is a good fit for this situation. It is a fit. It is not "the optimal fit", which is what this whole thread has been about -- system engineers, like me and Richard, compalining about the process itself not being meta-engineered. > The problem is that there isn't a good alternative to current for people > who expect a buildable tree. This was one soloution I suggested; internalize -current using a modification of Jordan't "build cookie" approach, to get away from 6 out of 7 machines claiming "well, it built fine for me". The only difference between that and the existing situation is that it would be machines posting in cookie space instead of humans posting on -current -- that is, they are topologically equivalent. > The focus should be put on an automated way of providing a buildable tree > and advertising it as the tree that most people should be downloading. Yes, I agree. The problem with the current discussion is not the abundance of discussion, it's the lack of implementation. This is the same problem that hits every 3-4 months. Novell had this same problem: they are a large company that want's to be a small company. Each time they acquire a company, they institute lay-offs until the number of employees drops below the critical mass at which "the good ol' boy network" method of working fails. They do this to kickstart "the good ol' boy network" back into usability. They do the same thing in many different ways. They do it by centralizing accounting, payroll, and other services, to reduce their mass. More recently, they moved many of their employees to a central campus, the better to increase the maximum head cound before the G.O.B.N. breaks down, again. They are unwilling to change their model to accomodate their growth, and so their growth fails. One possible soloution for Novell is "the holding company" approach. If I own all companies in a given market segment, it's really irrelevent if they compete: I am making all of the money to be made in that market segment, not matter how I am organized. So I should chose the organization with the best stability for the conditions instead of trying to use my hammer to turn every organization into a nail. The "core team" methodology is a single tier G.O.B.N.; it differs from the Novell G.O.B.N. only in scale, and only then because the incentives in a volunteer effort are less than those in a commercial effort (something the GNU idealogues do not apparently understand). The relative critical mass of a G.O.B.N. before it fragments under unternal pressure is directly proportional to the strength of the incentives involved. It is unprofessional to have to rely on someone to do something because "they are your buddy" as opposed to relying on them to do something because "it's their job to do it". In a volunteer effort, the line is more fuzzy, but it is still there. People get involved in a volunteer effort for "payment". It is not worth discussing whether this payment is real, and comes from Walnut Creek or whereever, or whether it's more ephemeral. The fact is that there is payment, and the payment should be sufficient to incent people to do what they need to, and ought to, do. The problem with the G.O.B.N., which is already in place, is twofold: it's inertia from already being in place, and the reluctance of the "insiders" to adopt a model which is more favorable to the groups goals than to their personal goals. The problem is the model. You will not make the problem go away by making the model operate to a higher critical mass; you will only increase the pressures, and the resulting explosive force when the critical mass is exceeded. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 10:29:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22225 for current-outgoing; Wed, 4 Sep 1996 10:29:25 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22218 for ; Wed, 4 Sep 1996 10:29:17 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id KAA00495; Wed, 4 Sep 1996 10:20:07 -0700 (PDT) Message-ID: <322DB9FE.446B9B3D@whistle.com> Date: Wed, 04 Sep 1996 10:18:54 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Developer CC: freebsd-current@freebsd.org Subject: Re: HELP URGENT!!! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Developer wrote: > Thanks for all your help:) The strange thing is when we rebooted the > machine again this morning it booted up just fine!! I wonder if it could > be a hardware error? maybet teh drive was hot? power supply low? From owner-freebsd-current Wed Sep 4 10:32:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22412 for current-outgoing; Wed, 4 Sep 1996 10:32:49 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA22399 for ; Wed, 4 Sep 1996 10:32:47 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA18207; Wed, 4 Sep 1996 13:31:18 -0400 Date: Wed, 4 Sep 1996 13:31:18 -0400 From: Garrett Wollman Message-Id: <9609041731.AA18207@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: michaelh@cet.co.jp (Michael Hancock), jkh@time.cdrom.com, rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure In-Reply-To: <199609041713.KAA06682@phaeton.artisoft.com> References: <199609041713.KAA06682@phaeton.artisoft.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk < said: > It is a fit. It is not "the optimal fit", which is what this whole thread > has been about -- system engineers, like me and Richard, compalining about > the process itself not being meta-engineered. And those of us who are actually doing useful work complain about too much flamage about the process from those who aren't. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Wed Sep 4 10:35:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22581 for current-outgoing; Wed, 4 Sep 1996 10:35:38 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22576 for ; Wed, 4 Sep 1996 10:35:36 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id KAA03862; Wed, 4 Sep 1996 10:34:36 -0700 (PDT) To: Terry Lambert cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 09:34:54 PDT." <199609041634.JAA06605@phaeton.artisoft.com> Date: Wed, 04 Sep 1996 10:34:36 -0700 Message-ID: <3859.841858476@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Adding latency is not the same thing as adding a "choke-point"; the only > increasingly hypothetical thing here is the idea that a broken source > tree is less of a barrier to progress than an increased latency for I was talking about a choke point for the developers, not the users. Multiple make worlds running simultaneously don't work out very well, last I checked, and it'd have to be something more like the public bus system model than the private auto model we have now (you climb in and drive whenever you like). Like I said before, I think centralizing it would be a mistake and the real answer to simply fix the build process so that it's less sensitive to anything outside its own build area. > of too much installed software on the ports machine. Or if we believe > Richard (and I happen to believe him), a result of failed segregation > of host/build environments. Right. > This will help in the external dependencies case, but it won't help in > the "agregate changes fail to compile" case -- which seems to be the Why not? There are two ways in which you can easily generate a bogus check build - bad source syncronization and external data pollution. Fixing the tree doesn't avoid bad source sync, that's true, but it does go a long way towards dealing with the second vulnerability. I believe source sync is also manageable through reasonable use of CVSup and CTM, though we still have yet to settle on the "trust" scheme used to tell people when it's safe to go in the water. Jordan From owner-freebsd-current Wed Sep 4 10:58:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA23752 for current-outgoing; Wed, 4 Sep 1996 10:58:59 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA23744 for ; Wed, 4 Sep 1996 10:58:56 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA06834; Wed, 4 Sep 1996 10:57:09 -0700 From: Terry Lambert Message-Id: <199609041757.KAA06834@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 4 Sep 1996 10:57:09 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Sep 3, 96 08:05:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Actually, you could seperate the process using a covert channel for the > >checkout for the build server: > > > >2) copy active cvs tree on repository to statis cvs tree on > > build server > >5) copy successfully test-built static cvs tree on build server > > to distribution cvs tree on distribution server (could be > > the same machine, the repository, or could be a third machine) > > As I have said, we don't need to worry about the distribution of "cvs" > trees. If I have such a tree, I can check out the (redefined) "current" > distribution without worrying whether or not it is the "head" or if "head" > is buildable at the present time. > > What we need to "limit" is the access known as "current". Updates of that > version would be subject to the "buildability" test. How can you tell the difference between a copy-time inconsistency that results from a copy interleaving with a checkin process, as opposed to an artifact in the cvs tree itself causing the inconsistency? This is, in fact, my problem with the "token/vote" scenario. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:01:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA23872 for current-outgoing; Wed, 4 Sep 1996 11:01:14 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA23867 for ; Wed, 4 Sep 1996 11:01:11 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id LAA03949; Wed, 4 Sep 1996 11:00:53 -0700 (PDT) To: John Polstra cc: current@FreeBSD.org, sja@tekla.fi Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 10:13:55 PDT." <199609041713.KAA18153@austin.polstra.com> Date: Wed, 04 Sep 1996 11:00:53 -0700 Message-ID: <3947.841860053@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Here is a related idea I've been toying with. I think I could easily > extend CVSup to support "pseudo-tags". These would be like CVS tags, > except they wouldn't really exist in the repository. Instead, the CVSup > server would know about them. A pseudo-tag would correspond to some > date on some branch. The user could request an update for a pseudo-tag > exactly as he now gets an update for a real tag. Warp^H^H^H^Hgreat minds think alike. :-) I was just thinking about that this morning, wondering how tags could be made "lighter weight" in some way so that you could slap them down whenever you wanted to mark some milestone and not have to worry about the cost of full-blown cvs tags. It sounds like your idea will handle one kind of application for tags, though I don't know how well it would work in the cases where you want to stamp out lots of unique tags, rather than continuously updating one "pseudo-tag" entry. Lots of people number their builds, for example, and it'd be kind nice if you could tell someone "build #2347 was pretty good - why don't you take the customer a tape of that?" and know that 2347 was "tagged" just as builds 2346 and 2348 were. If you could even slide these tags up and down files on an individual basis so the buildmeister for 2347 could treat it like a real tag, you'd have extended cvs usefulness considerably (but doing it all in cvsup, thus leaving cvs's "native tags" completely undisturbed). It's a neat idea, adding another layer to cvs's tagging in cvsup. Stick a reasonably powerful "tag database" model into this and I can even see addressing some of cvs's other annoyances. You could go pretty berserk with this concept, in fact! :-) Jordan From owner-freebsd-current Wed Sep 4 11:05:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA24137 for current-outgoing; Wed, 4 Sep 1996 11:05:25 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA24125 for ; Wed, 4 Sep 1996 11:05:20 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06857; Wed, 4 Sep 1996 11:03:10 -0700 From: Terry Lambert Message-Id: <199609041803.LAA06857@phaeton.artisoft.com> Subject: Re: Food for thought To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 4 Sep 1996 11:03:10 -0700 (MST) Cc: rkw@dataplex.net, msmith@atrad.adelaide.edu.au, current@FreeBSD.org In-Reply-To: <199609040425.NAA03285@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Sep 4, 96 01:55:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I disagree about the adequacy of "snap" releases. Jordan seems to get them > > out perhaps once a month. (I'm not faulting him) There are those who want > > to help check out things with much less latency, like maybe a day. The only > > problem is that they don't want to spend all of their time just getting the > > build to work. > > You are totally beyond reason, I'm afraid. You want stuff to be "stable", > but you expect the whole testing process to produce a lag of less than a > _day_? What sort of billion-dollar empire do you think FreeBSD inc. is?? Actually, Jordan has suggested 2 ways of achieving this. I've suggested 2 more -- one of which is a simple optimization of one of Jordan's, to reduce latency. Michael Hancock has suggested a fifth way, which is topologically equivalent to the other one of mine, without the consistency guarantees that a checkout does not occur while a checkin is in progress. This could be easily arbitrated by "hiding" the resource, either seperating it, or making it temporarily unavailable during the checkout-for-build. Process, one istituted, is self-sustaining. We do not need to build a coal-fired power-plant to enable us to use *any* of the processes suggested. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:12:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA24556 for current-outgoing; Wed, 4 Sep 1996 11:12:45 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA24550 for ; Wed, 4 Sep 1996 11:12:35 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06875; Wed, 4 Sep 1996 11:09:40 -0700 From: Terry Lambert Message-Id: <199609041809.LAA06875@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 11:09:39 -0700 (MST) Cc: jdp@polstra.com, current@FreeBSD.org, sja@tekla.fi In-Reply-To: <697.841811654@time.cdrom.com> from "Jordan K. Hubbard" at Sep 3, 96 09:34:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Terry, of course, would request that cvsup ask an external data > abstraction layer for all its resource information, allowing > one to say things like: > > % cvsup -release=cvs -host=cvsup.freebsd.org -hostbase=/home \ > -base=/usr -prefix=/home/ncvs -options delete,old \ > -coll=src-bin -coll=src-contrib -coll=ports-all Well, "hostbase" and "prefix", anyway... I think the SUP files should supped along with everything else so that at most you are one day behind on a consistent tree (John and I talked about this offline already, and the ramifications for "merge" on commented out lines for a partial SUP as opposed to the whole thing). > Despite the fact that I seem to be poking fun at it, I'm also in > agreement with Terry that allowing a tool to be "driven" as > generically as possible is a good thing, I'm just still waiting for > someone to contribute a "command and resource driver" library which > makes it easy to instrument new and existing applications in this way > without substantially reinventing the wheel for each and every one. I have already built a partition management and a user/group management tool to an interface definition. I am currently working out a specification grammar to reduce the necessary work in defining an interface (right now, it requires a yacc and a lex program written to exacting structural specifications to allow it to interact with the GUI). I'm afraid that much of what I have so far looks a lot like CLD's from VMS. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:18:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA24844 for current-outgoing; Wed, 4 Sep 1996 11:18:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA24839 for ; Wed, 4 Sep 1996 11:18:36 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06916; Wed, 4 Sep 1996 11:15:54 -0700 From: Terry Lambert Message-Id: <199609041815.LAA06916@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jdp@polstra.com (John Polstra) Date: Wed, 4 Sep 1996 11:15:54 -0700 (MST) Cc: jkh@time.cdrom.com, current@FreeBSD.org In-Reply-To: <199609041421.HAA17141@austin.polstra.com> from "John Polstra" at Sep 4, 96 07:21:59 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Whatever. Just so long as I get to use the word "meta-configuration" at > least once in the manual page. ;-) Heh. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:20:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25029 for current-outgoing; Wed, 4 Sep 1996 11:20:30 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA25023; Wed, 4 Sep 1996 11:20:28 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id LAA17516 ; Wed, 4 Sep 1996 11:18:51 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06901; Wed, 4 Sep 1996 11:14:31 -0700 From: Terry Lambert Message-Id: <199609041814.LAA06901@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jhs@FreeBSD.org Date: Wed, 4 Sep 1996 11:14:31 -0700 (MST) Cc: sja@tekla.fi, current@FreeBSD.org In-Reply-To: <199609040849.KAA00828@vector.jhs.no_domain> from "Julian H. Stacey" at Sep 4, 96 10:49:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Hi, Reference: > > From: sja@tekla.fi (Sakari Jalovaara) > > Subject: Re: Latest Current build failure > > Date: Tue, 3 Sep 1996 11:27:34 +0300 > > Message-id: <9609030827.AA05232@tahma.tekla.fi> > > > > How about this idea: > > > > Everyone cvsups the bleeding edge RCS files. > > NO ! That assumes everyone has good net connectivity ... & they don't all. > CTM has distinct advantages for maintenance of my local CVS tree, > namely, only my local ISP needs be up to supply the mail, > even if the rest of the net, or freebsd servers are dead or slow as hell... > no problem ! You are missing the forest for the trees. Please replace "cvsups" with "somehow obtains". The point of the suggestion was to externalize the "it's good" token from the tree representation. Other than adding that I'd like to see the "it's good" token checked into the tree somewhere as well so there is an "it's good" history (the token approach relies on the idea that the tree itself does not have to be kept "good"), I have to agree that this is a workable, if suboptimal, fix for the problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:25:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25270 for current-outgoing; Wed, 4 Sep 1996 11:25:04 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA25251 for ; Wed, 4 Sep 1996 11:24:40 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06943; Wed, 4 Sep 1996 11:20:30 -0700 From: Terry Lambert Message-Id: <199609041820.LAA06943@phaeton.artisoft.com> Subject: Re: Latest Current build failure - Reply To: darrend@novell.com (Darren Davis) Date: Wed, 4 Sep 1996 11:20:29 -0700 (MST) Cc: michaelh@cet.co.jp, terry@lambert.org, rkw@dataplex.net, current@FreeBSD.org, jkh@time.cdrom.com In-Reply-To: from "Darren Davis" at Sep 4, 96 09:59:36 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> At Novell, using CVS with a reader/writer lock front end, we were > >> able to keep a project with 18+ engineers hacking on it 8-12 hours > >> a day buildable for every night but 5 for a period of 8 months. > >> Further, we did it on three machine architectures. > > > >With fulltime engineers in how many time zones? > > We have fulltime engineers in San Jose CA, Provo UT, and India. We used > to have a bunch of engineers in Summit NJ, but not to many anymore. All > these timezones are still working on the source tree that Terry is talking > about. Actually, I was referring to the NWU code base only. But as Darren points out, there are several projects that fit the bill; his example is better because it has four time zones instead of three. Time zones are not a sufficient reason for throwing out the baby with the bathwater -- the point of both examples. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:29:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25561 for current-outgoing; Wed, 4 Sep 1996 11:29:51 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA25555 for ; Wed, 4 Sep 1996 11:29:48 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06978; Wed, 4 Sep 1996 11:27:33 -0700 From: Terry Lambert Message-Id: <199609041827.LAA06978@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: wollman@lcs.mit.edu (Garrett Wollman) Date: Wed, 4 Sep 1996 11:27:33 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, jkh@time.cdrom.com, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <9609041731.AA18207@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Sep 4, 96 01:31:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > It is a fit. It is not "the optimal fit", which is what this whole thread > > has been about -- system engineers, like me and Richard, compalining about > > the process itself not being meta-engineered. > > And those of us who are actually doing useful work complain about too > much flamage about the process from those who aren't. And those of us who are also doing useful work object to the scope of your definition of "useful" being context bound to those who are already members of the core team. To be blunt, Uther Pendragon complained about about "flamage" as well, as he went out with his small cadre to build England. The process involved was not a benefit to those not in the self-appointed class "fuedal lord", whose lacking attribute distinguishing them was their unwillingness to ride rough-shod over their fellows to advance themselves. Please consider the situation from the standpoint of project rather than personal goals. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:55:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA26780 for current-outgoing; Wed, 4 Sep 1996 11:55:47 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA26774 for ; Wed, 4 Sep 1996 11:55:45 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07039; Wed, 4 Sep 1996 11:52:13 -0700 From: Terry Lambert Message-Id: <199609041852.LAA07039@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: nate@mt.sri.com (Nate Williams) Date: Wed, 4 Sep 1996 11:52:13 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <199609041739.LAA00876@rocky.mt.sri.com> from "Nate Williams" at Sep 4, 96 11:39:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > [ One more time... ] > > This assumes that the writer lock is held over the build process; if it > > were a nightly build run by cron on another box, then it would work as > > well as the engineer's personal box. > > Writer lock won't solve any problems experienced in FreeBSD. It's been > discussed to death. It's a solution waiting for a problem that doesn't > exist. The problem doesn't exist in FreeBSD. Quit wasting everyones > time and mailboxes with your solution to a non-existant problem. It solves a problem in the suggested replacement for the existing system. Replacing the existing system solves the problems experienced by FreeBSD. I have never claimed writer locks to be anything other than supporting infrastructure for a more general soloution to a problem that is not, in current implementation, related to lack or existance of writer locks. By examining writer locks in the context of the current framework, you are doing me an injustice. Please quit assuming context for me. When I speak of writer locks, I am not speaking in the context of the existing system (which I believe has a sufficient volume of evidence noting its flaws). Like Richard's suggested build process reorganization, I expected there to be requirements that I provide a working example of a replacement. The working example I chose included writer locks as a necessary, *not* sufficient, condition. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:57:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA26879 for current-outgoing; Wed, 4 Sep 1996 11:57:55 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA26873 for ; Wed, 4 Sep 1996 11:57:47 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.7.5/8.6.9) with SMTP id TAA16834; Wed, 4 Sep 1996 19:56:58 +0100 (BST) Date: Wed, 4 Sep 1996 19:56:57 +0100 (BST) From: Developer To: Julian Elischer cc: freebsd-current@freebsd.org Subject: Re: HELP URGENT!!! In-Reply-To: <322DB9FE.446B9B3D@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 4 Sep 1996, Julian Elischer wrote: > Developer wrote: > > > Thanks for all your help:) The strange thing is when we rebooted the > > machine again this morning it booted up just fine!! I wonder if it could > > be a hardware error? > > maybet teh drive was hot? > power supply low? Yeh, I guess so. Regards, Trefor S. From owner-freebsd-current Wed Sep 4 11:58:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA26907 for current-outgoing; Wed, 4 Sep 1996 11:58:32 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA26899 for ; Wed, 4 Sep 1996 11:58:24 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07024; Wed, 4 Sep 1996 11:46:40 -0700 From: Terry Lambert Message-Id: <199609041846.LAA07024@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 11:46:40 -0700 (MST) Cc: terry@lambert.org, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <3859.841858476@time.cdrom.com> from "Jordan K. Hubbard" at Sep 4, 96 10:34:36 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Adding latency is not the same thing as adding a "choke-point"; the only > > increasingly hypothetical thing here is the idea that a broken source > > tree is less of a barrier to progress than an increased latency for > > I was talking about a choke point for the developers, not the users. > Multiple make worlds running simultaneously don't work out very well, > last I checked, and it'd have to be something more like the public bus > system model than the private auto model we have now (you climb in and > drive whenever you like). Like I said before, I think centralizing it > would be a mistake and the real answer to simply fix the build process > so that it's less sensitive to anything outside its own build area. First of all, the users of the source tree *are* developers. Second, I would not disagree with the auto model if it were possible to grant everyone a license. This is technically infeasible, despite the fact it is the model OpenBSD claims to have adopted. OpenBSD will get to the point where the model fails at some point in the near future, and then they will have to restrict licenses to drive, or change their transpaortation model entirely. > > This will help in the external dependencies case, but it won't help in > > the "agregate changes fail to compile" case -- which seems to be the > > Why not? There are two ways in which you can easily generate a bogus > check build - bad source syncronization and external data pollution. > Fixing the tree doesn't avoid bad source sync, that's true, but it > does go a long way towards dealing with the second vulnerability. I > believe source sync is also manageable through reasonable use of CVSup > and CTM, though we still have yet to settle on the "trust" scheme used > to tell people when it's safe to go in the water. Because the feedback cycle which would enforce good practice by any other method than self-control is not there in the model. And humans are inherently incapable of exercising sufficient self control to cause the resulting construct to be stable in the long term. Otherwise humans would not have wars (among other problems relating to human nature). This is just another topological equivalent of the current model; it will work for 3-4 months, until the cost of personal inconvenience outweigh the cost of exerting self-control. Then *BOOM*, we are back discussing "why is the source tree broken" instead of "how is it that the process allows the source tree to become broken", or "how do we design a process that will drag it back to unbroken, like a satellite at L4 is dragged back into position". The saddle point of the effort of the resulting process needs to be centered at "unbroken tree". Rely on human nature, not human benevolence, to ensure hysterisis. Do it by codifying a process that promotes the desired result instead of a shortest-route process. The shortest route is not the lowest energy route; think of it in terms or obrital mechanics. If you want a permanent fix, then instead of trying to fix the results of the process, fix the process so it can't produce broken results. Then we never need to discuss the issue ever again, instead of 3-4 months down the road, the whole thing blowing up again. Check the -current list archives. I believe the problem is systemic, though I'm willing to be proven wrong by an examination of history. If there isn't a cyclic pattern to these discussions, I'm willing to simply shut up -- since I won't have to deal with the issue again: if it's not systemic, it won't repeat. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 11:59:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA26957 for current-outgoing; Wed, 4 Sep 1996 11:59:34 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA26951 for ; Wed, 4 Sep 1996 11:59:27 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA28754 (5.65c/IDA-1.5 for ); Wed, 4 Sep 1996 11:57:56 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id NAA04445; Wed, 4 Sep 1996 13:55:34 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Sep 1996 13:55:34 -0500 To: John Polstra From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I was thinking some more about an idea Jordan brought up: > >> Actually, all you'd need to do is have your cvsup file modified to >> use a specific date in updating a previously checked out version >> of HEAD. > >Here is a related idea I've been toying with. I think I could easily >extend CVSup to support "pseudo-tags". > The cutoff date could be read from a configuration file on the server. The cutoff date can also be distributed. >That seems better than asking the users to change their cutoff dates all >the time. Why so? The same mechanism that selects the cutoff date on the server can be automatically applied at the user's end. There is no penalty for the user to "pre-fetch" additional updates. In fact, they might be useful. From owner-freebsd-current Wed Sep 4 12:23:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27912 for current-outgoing; Wed, 4 Sep 1996 12:23:59 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA27902 for ; Wed, 4 Sep 1996 12:23:52 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id MAA18911; Wed, 4 Sep 1996 12:23:10 -0700 (PDT) Message-Id: <199609041923.MAA18911@austin.polstra.com> To: rkw@dataplex.net (Richard Wackerbarth) cc: current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 13:55:34 CDT." Date: Wed, 04 Sep 1996 12:23:10 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Here is a related idea I've been toying with. I think I could easily > >extend CVSup to support "pseudo-tags". > > The cutoff date could be read from a configuration file on the server. > The cutoff date can also be distributed. Well, sure. I was just proposing an alternative mechanism. > >That seems better than asking the users to change their cutoff dates all > >the time. > > Why so? The same mechanism that selects the cutoff date on the server can > be automatically applied at the user's end. There is no penalty for the > user to "pre-fetch" additional updates. In fact, they might be useful. The existence of pseudo-tags wouldn't prevent users from doing anything. It would just be an additional convenience, for those who chose to use it. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Wed Sep 4 12:29:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA28194 for current-outgoing; Wed, 4 Sep 1996 12:29:13 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA28182 for ; Wed, 4 Sep 1996 12:29:06 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id MAA04332; Wed, 4 Sep 1996 12:18:24 -0700 (PDT) To: Terry Lambert cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 11:46:40 PDT." <199609041846.LAA07024@phaeton.artisoft.com> Date: Wed, 04 Sep 1996 12:18:24 -0700 Message-ID: <4330.841864704@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I think I'm coming around to the best "solution" of all to this, at least from my personal perspective, and that's to do nothing and leave -current exactly as it is. I'm tired out just talking about it now. :-) Jordan From owner-freebsd-current Wed Sep 4 12:46:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA28817 for current-outgoing; Wed, 4 Sep 1996 12:46:39 -0700 (PDT) Received: from jupiter.stochastik.rwth-aachen.de (root@jupiter.Stochastik.RWTH-Aachen.DE [137.226.106.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA28812 for ; Wed, 4 Sep 1996 12:46:35 -0700 (PDT) Received: from saturn.stochastik.rwth-aachen.de (saturn.stochastik.rwth-aachen.de [137.226.106.8]) by jupiter.stochastik.rwth-aachen.de (8.7.4/BuGless_1.03/MS1.00) with ESMTP id VAA01607 for ; Wed, 4 Sep 1996 21:45:03 +0200 (MET DST) From: Guido Muesch Received: (from odiug@localhost) by saturn.stochastik.rwth-aachen.de (8.7.5/BuGless_fw_1.01) id VAA03670 for current@freebsd.org; Wed, 4 Sep 1996 21:43:21 +0100 (WET DST) Message-Id: <199609042043.VAA03670@saturn.stochastik.rwth-aachen.de> Subject: booting from SCSI problem To: current@freebsd.org Date: Wed, 4 Sep 1996 21:43:21 +0100 (WET DST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have two hard drives: One IDE (170MB DOS) and one SCSI (2GB with FreeBSD in first slice) and booteasy installed in both MBRs. After first installing FreeBSD without checking out the Bios geometry of the drive I could not boot FreeBSD. OK, I read about the >1GB problem with SCSI disks and Bios later and reinstalled FreeBSD. Bootprocess is now as follows: F5 -> switch to SCSI disk. F1 -> booting kernel from first slice of the SCSI disk. The kernel boots fine, but thinks the SCSI disk is sd(1,a) and so fails to mount the root partition. OK, I can type '-r' all the time to get the compiled in rootdevice. But can this not be made the default? Or am I missing something else? Ciao Guido From owner-freebsd-current Wed Sep 4 12:52:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA29057 for current-outgoing; Wed, 4 Sep 1996 12:52:04 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA29012 for ; Wed, 4 Sep 1996 12:51:58 -0700 (PDT) Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id PAA25137; Wed, 4 Sep 1996 15:49:53 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: michaelh@cet.co.jp (Michael Hancock), jkh@time.cdrom.com, rkw@dataplex.net, current@FreeBSD.org From: "Gary Palmer" Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 10:13:19 PDT." <199609041713.KAA06682@phaeton.artisoft.com> Date: Wed, 04 Sep 1996 15:49:52 -0400 Message-ID: <25133.841866592@orion.webspan.net> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote in message ID <199609041713.KAA06682@phaeton.artisoft.com>: > > > At Novell, using CVS with a reader/writer lock front end, we were > > > able to keep a project with 18+ engineers hacking on it 8-12 hours > > > a day buildable for every night but 5 for a period of 8 months. > > > Further, we did it on three machine architectures. > > > > With fulltime engineers in how many time zones? > > Three. Utah (MST), Texas (CST), and New Jersey (PST). We also had Really? Since when did New Jersey change coastlines? :-) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-current Wed Sep 4 13:24:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA00622 for current-outgoing; Wed, 4 Sep 1996 13:24:22 -0700 (PDT) Received: from ns.eu.org (valerian.glou.eu.org [193.56.58.251]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA00541 for ; Wed, 4 Sep 1996 13:23:54 -0700 (PDT) Received: (from uucp@localhost) by ns.eu.org (8.7.3/8.7.1/951117) with UUCP id WAA18045; Wed, 4 Sep 1996 22:23:43 +0200 (MET DST) Received: (from regnauld@localhost) by tetard.glou.eu.org (8.7.5/8.7.3/tetard-uucp-2.7) id UAA01407; Wed, 4 Sep 1996 20:32:08 +0200 (MET DST) From: Philippe Regnauld Message-Id: <199609041832.UAA01407@tetard.glou.eu.org> Subject: Re: Food for thought To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 20:32:07 +0200 (MET DST) Cc: current@freebsd.org (current) In-Reply-To: <618.841810591@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 3, 96 09:16:31 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard écrit / writes: > > Anyone who wants "head" MUST get it by cvs. > > Ah, and if only Hugh Grant had heeded this sage advice! :-) Who's got an appropriate acronym for 'cvs', now ? . -- Phil -- -[ Philippe Regnauld / regnauld@eu.org / +55.4N +11.3E @ Sol3 / +45 31241690 ]- -[ "To kårve or nøt to kårve, that is the qvestion..." -- My sister ]- From owner-freebsd-current Wed Sep 4 13:31:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA00922 for current-outgoing; Wed, 4 Sep 1996 13:31:40 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA00902; Wed, 4 Sep 1996 13:31:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07276; Wed, 4 Sep 1996 13:29:34 -0700 From: Terry Lambert Message-Id: <199609042029.NAA07276@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: gpalmer@FreeBSD.org (Gary Palmer) Date: Wed, 4 Sep 1996 13:29:34 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, jkh@time.cdrom.com, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <25133.841866592@orion.webspan.net> from "Gary Palmer" at Sep 4, 96 03:49:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Three. Utah (MST), Texas (CST), and New Jersey (PST). We also had > > Really? Since when did New Jersey change coastlines? :-) You know USL... heh. Should have been EST... sorry about that. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 13:38:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA01409 for current-outgoing; Wed, 4 Sep 1996 13:38:13 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA01403 for ; Wed, 4 Sep 1996 13:38:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07326; Wed, 4 Sep 1996 13:36:01 -0700 From: Terry Lambert Message-Id: <199609042036.NAA07326@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: nate@mt.sri.com (Nate Williams) Date: Wed, 4 Sep 1996 13:36:01 -0700 (MST) Cc: terry@lambert.org, nate@mt.sri.com, current@freebsd.org In-Reply-To: <199609041858.MAA01487@rocky.mt.sri.com> from "Nate Williams" at Sep 4, 96 12:58:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It solves a problem in the suggested replacement for the existing system. > > No, it doesn't. As has been discussed to death in the past, it solves > *NO* problems in the past or present that can be solved. The *problem* > is a human problem that can't be solved adequately using a computer. It > needs human intervention (ala. Jordan's cookies). No 'locking' protocol > within CVS will solve the problem, as the problem exists outside the > scope of the version control software. > > 'Nuff said, you can continue to waste both my time and others, but it > will be ignored. while( cookie not present) continue; Looks like a damn lock to me. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 13:42:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA01612 for current-outgoing; Wed, 4 Sep 1996 13:42:39 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA01587 for ; Wed, 4 Sep 1996 13:42:02 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id NAA17692 for ; Wed, 4 Sep 1996 13:42:01 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07260; Wed, 4 Sep 1996 13:28:20 -0700 From: Terry Lambert Message-Id: <199609042028.NAA07260@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 13:28:20 -0700 (MST) Cc: terry@lambert.org, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <4330.841864704@time.cdrom.com> from "Jordan K. Hubbard" at Sep 4, 96 12:18:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I think I'm coming around to the best "solution" of all to this, at > least from my personal perspective, and that's to do nothing and leave > -current exactly as it is. > > I'm tired out just talking about it now. :-) Be prepared to revisit this discussion every 3-4 months, as we have for several years now, then, for the same reasons: tabling an issue does not resolve it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 13:50:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA01977 for current-outgoing; Wed, 4 Sep 1996 13:50:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA01963 for ; Wed, 4 Sep 1996 13:50:32 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07361; Wed, 4 Sep 1996 13:45:30 -0700 From: Terry Lambert Message-Id: <199609042045.NAA07361@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: nate@mt.sri.com (Nate Williams) Date: Wed, 4 Sep 1996 13:45:30 -0700 (MST) Cc: terry@lambert.org, rkw@dataplex.net, current@freebsd.org In-Reply-To: <199609041904.NAA01512@rocky.mt.sri.com> from "Nate Williams" at Sep 4, 96 01:04:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As stated, it's simply not a problem worth messing with. (BTW, early > versions of CVS used a single 'write-lock' scheme, but after testing it > was considered overkill hence the 'new' scheme which used directory-lock > schemes.) A recent discussion of this point went on in devel-cvs. You and I both know that a directory lock schema fails when there is implied context spanning multiple directories. For instance, when a manifest constant is changed in a header file, but used in multiple source files in multiple directories. The problem with tree inconsistency at present is that it is possible to copy the tree while it is in transit from an inconsistent to a consistent state after starting in a consistent state. This assumes that there is policy in place to guarantee an initial consistent state (a supposition you seem unwilling to grant, given the material you chose to quote/not-quote in your response). Other than process failing to accommodate the possibility of human error, the is the only failure mode that can result in "hel, -current doesn't build!" mail messages. Note the use of the word "can". Would you argue that, because a race condition does not frequently cause problems, the race condition should not be eliminated? Before you answer, note that you are condemned by your own words from the argument that it would burden developers -- if the problem doesn't happen, then the conflict condition that would "burden" them will not occur. It is only a failure-mode saftey protocol. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 13:55:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02217 for current-outgoing; Wed, 4 Sep 1996 13:55:52 -0700 (PDT) Received: from groa.uct.ac.za (groa.uct.ac.za [137.158.128.7]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA02184 for ; Wed, 4 Sep 1996 13:55:34 -0700 (PDT) Received: by groa.uct.ac.za via sendmail with stdio id for current@freebsd.org; Wed, 4 Sep 1996 22:55:16 +0200 (SAT) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-21) Message-Id: From: rv@groa.uct.ac.za (Russell Vincent) Subject: Check out .depend To: current@freebsd.org Date: Wed, 4 Sep 1996 22:55:15 +0200 (SAT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just playing with CVsup (congratulations John - fantastic work!) and the following popped up: Checkout src/lib/libmd/.depend Should the '.depend' be in the CVS tree? Probably not a problem, but thought I would mention it. -Russell From owner-freebsd-current Wed Sep 4 13:56:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02303 for current-outgoing; Wed, 4 Sep 1996 13:56:15 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA02233 for ; Wed, 4 Sep 1996 13:55:58 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA20172 (5.65c/IDA-1.5 for ); Wed, 4 Sep 1996 13:54:28 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id PAA05678; Wed, 4 Sep 1996 15:45:37 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Sep 1996 15:45:47 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: terry@lambert.org, current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >I think I'm coming around to the best "solution" of all to this, at >least from my personal perspective, and that's to do nothing and leave >-current exactly as it is. > >I'm tired out just talking about it now. :-) As usual, the "powers that be" refuse to either make changes or allow others to do so. I described in detail an exact methodology which would at least allow us to test the assertions that "there is no problem". I even offered to coordinate the changes. However, since I'm not one of the "anointed few"...... The status quo wins again. :-( I'm afraid I'll have to side with Terry. (January or February ?) From owner-freebsd-current Wed Sep 4 14:23:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03432 for current-outgoing; Wed, 4 Sep 1996 14:23:59 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA03426 for ; Wed, 4 Sep 1996 14:23:53 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA02524; Wed, 4 Sep 1996 15:23:43 -0600 (MDT) Date: Wed, 4 Sep 1996 15:23:43 -0600 (MDT) Message-Id: <199609042123.PAA02524@rocky.mt.sri.com> From: Nate Williams To: rkw@dataplex.net (Richard Wackerbarth) Cc: "Jordan K. Hubbard" , terry@lambert.org, current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: References: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth writes: > >I think I'm coming around to the best "solution" of all to this, at > >least from my personal perspective, and that's to do nothing and leave > >-current exactly as it is. > > > >I'm tired out just talking about it now. :-) > > As usual, the "powers that be" refuse to either make changes or allow > others to do so. I think you give too much 'power' to the 'powers that be'. You're completely free to do anything you want. But, *FIRST* of all show a working prototype and *THEN* expect to be heralded as the hero. Put the cart before the horse, not the other way around. Nate ps. You don't have to be a 'core' member to commit to the tree, just a committer. From owner-freebsd-current Wed Sep 4 14:51:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04482 for current-outgoing; Wed, 4 Sep 1996 14:51:44 -0700 (PDT) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA04474 for ; Wed, 4 Sep 1996 14:51:30 -0700 (PDT) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id RAA16282 for current@freebsd.org; Wed, 4 Sep 1996 17:46:30 -0400 (EDT) From: Robin Cutshaw Message-Id: <199609042146.RAA16282@intercore.com> Subject: nfs related panic To: current@freebsd.org Date: Wed, 4 Sep 1996 17:46:27 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Running 2.2-960801-SNAP or current-smp with 1 or 2 cpu's active I get: panic : ufs_ihashget:recursive lock not expected -- pid 155 when running two or more nfs clients off of this box as a server (and building XFree86 312G remotely). Changing the number of nfsd's running had no effect. Fixed in -current? robin -- ---- Robin Cutshaw internet: robin@interlabs.com Internet Labs, Inc. BellNet: 404-817-9787 "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-current Wed Sep 4 14:54:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04634 for current-outgoing; Wed, 4 Sep 1996 14:54:16 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA04624 for ; Wed, 4 Sep 1996 14:54:07 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA03752 (5.65c/IDA-1.5 for ); Wed, 4 Sep 1996 14:52:30 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id QAA05984; Wed, 4 Sep 1996 16:50:00 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Sep 1996 16:50:00 -0500 To: Nate Williams From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: >I think you give too much 'power' to the 'powers that be'. You're >completely free to do anything you want. But, *FIRST* of all show a >working prototype and *THEN* expect to be heralded as the hero. > >Put the cart before the horse, not the other way around. Not in this case. This involves a policy change for the distribution of FreeBSD. THere is no way that I can modify the distribution channels without the "blessing" of the 'core'. What I propose is to have three tiers of distribution. At the top, we have those who either have direct access to the master tree or are willing to live with CVSup'ed images taken from it. At the next level, we have frequent snapshots of the tree. These are clocked by the ctm-cvs generator (every 6 hours, I believe). I would have the sup mirrors use this as their distributable product. The third level would be the "current" (or as someone said, "recent") tree. It would also be synced to the above mentioned distributions. However, the distribution can be delayed or skipped until some verfication of the "buildability" has been established. Initially, we can simply ignore "buildability" and release the updates on arrival. Later, we can put a release filter into the mechanism. The entire process is implemented with existing and tested components. I have now done as much as I reasonably can do without authorization to actually implement the scheme. Since this was previously presented along with the offer to coordinate the effort and has been rejected without explanation, I again present it as evidence supporting my attitude and refuting yours. I cannot do "what I want". Neither can I demonstrate a working modification to the make system without first removing a bunch of inappropriate absolute file references. But I cannot get anyone to agree to make those changes until I demonstrate that it all works. So which is the chicken and which is the egg in this case? From owner-freebsd-current Wed Sep 4 16:51:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09789 for current-outgoing; Wed, 4 Sep 1996 16:51:40 -0700 (PDT) Received: from bdd.net (bdd.net [207.61.119.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA09779 for ; Wed, 4 Sep 1996 16:51:37 -0700 (PDT) Received: from localhost (matt@localhost) by bdd.net (8.7.5/8.7.3) with SMTP id TAA02515 for ; Wed, 4 Sep 1996 19:51:34 -0400 (EDT) Date: Wed, 4 Sep 1996 19:51:34 -0400 (EDT) From: Matthew Stein To: freebsd-current@freebsd.org Subject: XFree86 on Current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The current X312E binaries avialable on ftp.freebsd.org are now out of date, and expire. Some of us require the betas, and can *almost* use the new F binaries available on ftp.xfree86.org. I say almost, because is built with libc.so.2.2, which is no longer in current. The X312E binaries in ftp.freebsd.org:/pub/FreeBSD/XFree86/2.2-CURRENT/XF86312E worked fine, but are out of date now. Are there plans to replace these binaries with ones that will run without the compat21 options? Or, am I just missing something? -- mat. +-Matthew Stein-------------------------------------------- matt@bdd.net-+ | Network Design phone: +1 519 823-8577 | | ButtonDown Digital fax: +1 519 823-9556 | +------------------------------------------------------------------------+ From owner-freebsd-current Wed Sep 4 18:18:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12356 for current-outgoing; Wed, 4 Sep 1996 18:18:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA12347 for ; Wed, 4 Sep 1996 18:17:32 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA07762; Wed, 4 Sep 1996 18:14:59 -0700 From: Terry Lambert Message-Id: <199609050114.SAA07762@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 4 Sep 1996 18:14:58 -0700 (MST) Cc: jkh@time.cdrom.com, terry@lambert.org, current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Sep 4, 96 03:45:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As usual, the "powers that be" refuse to either make changes or allow > others to do so. > > I described in detail an exact methodology which would at least allow us to > test the assertions that "there is no problem". I even offered to > coordinate the changes. However, since I'm not one of the "anointed > few"...... > The status quo wins again. :-( > > I'm afraid I'll have to side with Terry. (January or February ?) Understand that this is a process problem, not a "powers that be" problem. This is not a case of siding "with Terry" and "against the powers that be". This is a case of pointing at a broken process and saying out loud "Oh, look! A broken process!". If you are looking at this as a "powers that be" problem, then you are pointing at the effect and calling it the cause. The first step towards a fix is to allow the process to be changed, and to attack all the systemic problems from that angle. This will have the effect of relieving the pressure on Jordan and David, and it will then be possible to tackle the other, more meaningful, problems. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 18:26:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12628 for current-outgoing; Wed, 4 Sep 1996 18:26:10 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12623 for ; Wed, 4 Sep 1996 18:26:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id SAA18089 for ; Wed, 4 Sep 1996 18:26:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA07805; Wed, 4 Sep 1996 18:22:24 -0700 From: Terry Lambert Message-Id: <199609050122.SAA07805@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 18:22:23 -0700 (MST) Cc: terry@lambert.org, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <5176.841886288@time.cdrom.com> from "Jordan K. Hubbard" at Sep 4, 96 06:18:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Be prepared to revisit this discussion every 3-4 months, as we have > > for several years now, then, for the same reasons: tabling an issue > > does not resolve it. > > Nor does discussing it, apparently, as both avoidance and discussion > are currently tied 1-1 on their general ineffectiveness scores. > > We can either try for a new strategy or we can continue to fail with > the current ones for another 3 years, that's what it looks like to > me. What do you suggest for a third option? It seems to me that resolving to allow someone to implement something with the results of the discussion would change that to 1-0 on their relative ineffectiveness scores. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 18:28:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12719 for current-outgoing; Wed, 4 Sep 1996 18:28:54 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12714 for ; Wed, 4 Sep 1996 18:28:52 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id SAA05178; Wed, 4 Sep 1996 18:18:08 -0700 (PDT) To: Terry Lambert cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 13:28:20 PDT." <199609042028.NAA07260@phaeton.artisoft.com> Date: Wed, 04 Sep 1996 18:18:08 -0700 Message-ID: <5176.841886288@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Be prepared to revisit this discussion every 3-4 months, as we have > for several years now, then, for the same reasons: tabling an issue > does not resolve it. Nor does discussing it, apparently, as both avoidance and discussion are currently tied 1-1 on their general ineffectiveness scores. We can either try for a new strategy or we can continue to fail with the current ones for another 3 years, that's what it looks like to me. Jordan From owner-freebsd-current Wed Sep 4 18:47:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA13350 for current-outgoing; Wed, 4 Sep 1996 18:47:03 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA13343 for ; Wed, 4 Sep 1996 18:46:44 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA07943; Thu, 5 Sep 1996 11:15:32 +0930 From: Michael Smith Message-Id: <199609050145.LAA07943@genesis.atrad.adelaide.edu.au> Subject: Re: Latest Current build failure To: rkw@dataplex.net (Richard Wackerbarth) Date: Thu, 5 Sep 1996 11:15:32 +0930 (CST) Cc: nate@mt.sri.com, current@freebsd.org In-Reply-To: from "Richard Wackerbarth" at Sep 4, 96 04:50:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth stands accused of saying: > > Not in this case. This involves a policy change for the distribution > of FreeBSD. THere is no way that I can modify the distribution > channels without the "blessing" of the 'core'. You don't have to 'modify' anything. If you want to see your plans in action, you should be setting up the service _in_parallel_. Just because you can't convert the whole community to your One True Policy instantly is no reason not to try it. > At the top, we have those who either have direct access to the master tree > or are willing to live with CVSup'ed images taken from it. > > At the next level, we have frequent snapshots of the tree. These are > clocked by the ctm-cvs generator (every 6 hours, I believe). I would have > the sup mirrors use this as their distributable product. So far there is nothing new here. All this is already in place. > The third level would be the "current" (or as someone said, "recent") tree. > It would also be synced to the above mentioned distributions. However, the > distribution can be delayed or skipped until some verfication of the > "buildability" has been established. So you are proposing that there be a -recent thread, which is qualified as 'the last -current that survives a full build'. Ok, no problem there. > The entire process is implemented with existing and tested components. > > I have now done as much as I reasonably can do without authorization to > actually implement the scheme. Huh? Where is your test-build server? Where are your publically-released scripts that run 'make bootstrap;make world', and if the build fails restore the _entire_system_ to a previously-saved checkpoint state. > I cannot do "what I want". This doesn't follow from what you've just stated. The _only_ new element in your masterplan is the creation of the -recent thread, which as a direct derivative of -current, can be done by any site or sites currently using any of the -current update mechanisms. With access to sup/CVSup/CTM you can simulate reasonably accurately the master CVS repository from which all changes would be flowing. Then you can implement the downstream system(s) either with your own resources or with some volunteers. If your plan works, more will join the bandwagon. If it sinks, we don't go down with you. > Neither can I demonstrate a working modification to the make system without > first removing a bunch of inappropriate absolute file references. But I > cannot get anyone to agree to make those changes until I demonstrate that > it all works. And? Take your system, make the changes, submit a set of diffs and some descriptions of what they do and then advocate them. You seem to think that the only way to 'demonstrate' something is by forcing everyone else to 'walk this way' and refusing to explain it beforehand. This is not collaborative development; this is despotism. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Sep 4 19:03:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA14141 for current-outgoing; Wed, 4 Sep 1996 19:03:40 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA14135 for ; Wed, 4 Sep 1996 19:03:37 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id SAA05287; Wed, 4 Sep 1996 18:53:02 -0700 (PDT) To: rkw@dataplex.net (Richard Wackerbarth) cc: terry@lambert.org, current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 15:45:47 CDT." Date: Wed, 04 Sep 1996 18:53:01 -0700 Message-ID: <5285.841888381@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As usual, the "powers that be" refuse to either make changes or allow > others to do so. No, no, go for it - by all means! Just come back and talk to me when this whole system is ready for me to BETA test somewhere and I'll provide the well connected server and the disk space, OK? You hold up your end with the software, I'll hold up mine with the resources to house it - you can't get any fairer than that. I just don't have time to sit here debating the whole thing for n weeks first and this reality would be a far better one to occupy right now if, instead of reading you and Terry *talking* about a system, I saw you off in a corner together actually *implementing* a system. We need something more tangible to evaluate than 2 year's worth of mouldering emails or nothing will ever come of any of this. Jordan From owner-freebsd-current Wed Sep 4 19:10:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA14352 for current-outgoing; Wed, 4 Sep 1996 19:10:24 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA14347 for ; Wed, 4 Sep 1996 19:10:18 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id TAA20630; Wed, 4 Sep 1996 19:09:34 -0700 (PDT) Message-Id: <199609050209.TAA20630@austin.polstra.com> To: jkh@time.cdrom.com Cc: current@FreeBSD.org Subject: Re: Latest Current build failure Date: Wed, 04 Sep 1996 19:09:33 -0700 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Jordan wrote: > I think I'm coming around to the best "solution" of all to this, > at least from my personal perspective, and that's to do nothing > and leave -current exactly as it is. I've been reluctant to say it, but I tend to agree with that. The event that triggered this thread wasn't even really a problem with -current. It was cockpit error, or network Bermuda Triangle syndrome, or something like that. Nothing coming out of this thread would have made any difference. About the idea of having moving cutoff dates representing "better" not-quite-current versions: The same people who ignore the Handbook's caveats about -current would also ignore the "FreeBSD-recent" releases, and continue to get -current. "If recent is good, then current must be better!" And they would continue to complain when things didn't go just so for them. > I'm tired out just talking about it now. :-) Me too. Bye! John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Wed Sep 4 19:15:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA14473 for current-outgoing; Wed, 4 Sep 1996 19:15:04 -0700 (PDT) Received: from janai.thuvia.org (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA14461 for ; Wed, 4 Sep 1996 19:14:59 -0700 (PDT) Received: (from mark@localhost) by janai.thuvia.org (8.7.5/8.7.3) id DAA15778; Thu, 5 Sep 1996 03:14:47 +0100 (BST) Message-Id: <199609050214.DAA15778@janai.thuvia.org> From: mark@linus.demon.co.uk (Mark Valentine) Date: Thu, 5 Sep 1996 03:14:47 +0100 In-Reply-To: Robin Cutshaw's message of Sep 4, 5:46pm X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Robin Cutshaw , current@freebsd.org Subject: Re: nfs related panic Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Robin Cutshaw > Date: Wed 4 Sep, 1996 > Subject: nfs related panic > Running 2.2-960801-SNAP or current-smp with 1 or 2 cpu's active I get: > > panic : ufs_ihashget:recursive lock not expected -- pid 155 > > when running two or more nfs clients off of this box as a server (and > building XFree86 312G remotely). Changing the number of nfsd's running > had no effect. > > Fixed in -current? No, but Doug Rabson posted a fix that does the trick to the hackers list back in July (I just tracked it down and duly submitted it to the gnats system after stumbling over the bug at work today). It's reported to work with SunOS 5.5 and OSF/1 NFSv3 clients. Cheers, Mark. (This version of the fix is against rev. 1.32 of sys/nfs/nfs_serv.c.) --- nfs_serv.c.ctm Mon Sep 2 23:44:18 1996 +++ nfs_serv.c Wed Sep 4 22:55:23 1996 @@ -2899,6 +2899,7 @@ nfsm_srvpostop_attr(getret, &at); return (0); } + vput(nvp); dirlen = len = NFSX_V3POSTOPATTR + NFSX_V3COOKIEVERF + 2 * NFSX_UNSIGNED; nfsm_reply(cnt); -- Mark Valentine at Home From owner-freebsd-current Wed Sep 4 19:30:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA15075 for current-outgoing; Wed, 4 Sep 1996 19:30:32 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA15069 for ; Wed, 4 Sep 1996 19:30:26 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA26614 (5.65c/IDA-1.5 for ); Wed, 4 Sep 1996 19:28:55 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id VAA09890; Wed, 4 Sep 1996 21:25:35 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Sep 1996 21:25:36 -0500 To: Michael Smith From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: nate@mt.sri.com, current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Richard Wackerbarth stands accused of saying: >> >> Not in this case. This involves a policy change for the distribution >> of FreeBSD. THere is no way that I can modify the distribution >> channels without the "blessing" of the 'core'. > >You don't have to 'modify' anything. If you want to see your plans in >action, you should be setting up the service _in_parallel_. Just because >you can't convert the whole community to your One True Policy instantly >is no reason not to try it. Here I disagree. Unless, by policy, we eliminate the source of the problem, we have gained nothing. Further, we neither have the collective resources, nor avoid the confusion factor by adding another basically redundant distribution. >> At the top, we have those who either have direct access to the master tree >> or are willing to live with CVSup'ed images taken from it. >> >> At the next level, we have frequent snapshots of the tree. These are >> clocked by the ctm-cvs generator (every 6 hours, I believe). I would have >> the sup mirrors use this as their distributable product. > >So far there is nothing new here. All this is already in place. I didn't claim it was new. I am simply trying to be complete; to explain it. Actually there is a minor change in that the mirrors would, in my scheme be synced so that you could shift from one to another. >> The third level would be the "current" (or as someone said, "recent") tree. >> It would also be synced to the above mentioned distributions. However, the >> distribution can be delayed or skipped until some verfication of the >> "buildability" has been established. > >So you are proposing that there be a -recent thread, which is qualified as >'the last -current that survives a full build'. Ok, no problem there. >Huh? Where is your test-build server? Where are your publically-released >scripts that run 'make bootstrap;make world', and if the build fails >restore the _entire_system_ to a previously-saved checkpoint state. You missed the point that that is a second phase. The users gain some from the synchronization, but this step also prepares them for the next one. >> I cannot do "what I want". > >This doesn't follow from what you've just stated. The _only_ new element in >your masterplan is the creation of the -recent thread, which as a direct >derivative of -current, can be done by any site or sites currently >using any of the -current update mechanisms. With access to sup/CVSup/CTM >you can simulate reasonably accurately the master CVS repository from which >all changes would be flowing. Then you can implement the downstream >system(s) either with your own resources or with some volunteers. Poppycock! This works "by inspection". We simply have to get the distribution sites to standardize on an already proven mechanism. As for the "validation" stuff, you left out the migration path that said that we could start by assuming that each release was OK. The real thing that is different is that "current" would no longer exist in quite the same way as a bunch of unsynchronized snapshots. >If your plan works, more will join the bandwagon. If it sinks, we don't go >down with you. I cannot really give you anything of value until I have reworked the distribution system. There is the "critical mass" question. Without the "help" of the organization, this thing will never fly. If I have to compete on your terms, I might as well start yet another BSD derivative where I get to be "top dog". I don't want to do that, but your attitude continues to make it more attractive. >> Neither can I demonstrate a working modification to the make system without >> first removing a bunch of inappropriate absolute file references. But I >> cannot get anyone to agree to make those changes until I demonstrate that >> it all works. > >And? Take your system, make the changes, submit a set of diffs and some >descriptions of what they do and then advocate them. I am unwilling to tackle such a major project by myself without official approval. It is a case of shooting at a target that moves faster than I can. >You seem to think that the only way to 'demonstrate' something is by >forcing everyone else to 'walk this way' and refusing to explain it >beforehand. I've tried to explain it. All I get in reply is "You have to complete it and show me before I will discuss it" From owner-freebsd-current Wed Sep 4 19:36:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA15471 for current-outgoing; Wed, 4 Sep 1996 19:36:35 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA15466 for ; Wed, 4 Sep 1996 19:36:32 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA07941; Wed, 4 Sep 1996 19:32:55 -0700 From: Terry Lambert Message-Id: <199609050232.TAA07941@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 19:32:54 -0700 (MST) Cc: rkw@dataplex.net, terry@lambert.org, current@freebsd.org In-Reply-To: <5285.841888381@time.cdrom.com> from "Jordan K. Hubbard" at Sep 4, 96 06:53:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > As usual, the "powers that be" refuse to either make changes or allow > > others to do so. > > No, no, go for it - by all means! Just come back and talk to me when > this whole system is ready for me to BETA test somewhere and I'll > provide the well connected server and the disk space, OK? You hold up > your end with the software, I'll hold up mine with the resources to > house it - you can't get any fairer than that. I just don't have time > to sit here debating the whole thing for n weeks first and this > reality would be a far better one to occupy right now if, instead of > reading you and Terry *talking* about a system, I saw you off in a > corner together actually *implementing* a system. We need something > more tangible to evaluate than 2 year's worth of mouldering emails or > nothing will ever come of any of this. Well, since you include me, I will respond to this. And we need something more tangible than a promise to consider ideas only after they have been rendered into code. Like someone saying "this is what would please us" so it's possible to target the code to please the people that have to be pleased -- the group of people smaller than the whole who are in charge of vetting all code contributions. That's sort of the point of having discussions in the first place: to ask "what is the policy?" and keep asking until we get an answer other than "there is none". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 20:03:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA16470 for current-outgoing; Wed, 4 Sep 1996 20:03:50 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA16464 for ; Wed, 4 Sep 1996 20:03:47 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id TAA05414; Wed, 4 Sep 1996 19:52:00 -0700 (PDT) To: rkw@dataplex.net (Richard Wackerbarth) cc: Nate Williams , current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 16:50:00 CDT." Date: Wed, 04 Sep 1996 19:52:00 -0700 Message-ID: <5412.841891920@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Not in this case. This involves a policy change for the distribution > of FreeBSD. THere is no way that I can modify the distribution > channels without the "blessing" of the 'core'. This misapprehension is derived from a wholly inaccurate perception of how things work in this project, a form of myopia that 2 years worth of impassioned argument and occasional shouting has done absolutely nothing to dislodge. Richard, congraduations - I formally admit that you've beaten me fair and square. Your armor would appear to be impervious to every form of reason I'm capable of throwing at it. You win by forfeit. I've tried very hard to explain to Richard that things just can't work the way he wants them to, and I've explained that he really is putting the cart before the horse *from the FreeBSD development* perspective, if clearly not his own, in how he's trying to go about doing this grand build architecture of his. Rather than try to understand this or work towards any greater insights on a project he's purportedly trying to help, however, he's simply dug his heels in and fought all that much harder for the project to adapt to him rather than the other way around. Sigh. In case someone else should want to try this, I can only offer this advice: Design and build a prototype, show it off to everyone, we'll go from there. Hell, I'd *love* to have Joe Hacker send me email someday saying "Hey, your stuff in /usr/src/release sucked so I started over and wrote a new release tool, rewrote all the release-rolling stuff in general and untangled that mess of a source tree you guys had. Wanna look? Here are some diffs and a couple of sgml files I threw together which document the build system." Man, after picking my jaw up off the floor, you can bet your ass I'd look at it. If it was really good stuff, you'd probably see me jumping up in down in -hackers about an hour later screaming "Joe Hacker for president! Joe Hacker for God!" Guess we'll just have to wait until Joe Hacker shows up! :-) Jordan From owner-freebsd-current Wed Sep 4 20:09:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA16696 for current-outgoing; Wed, 4 Sep 1996 20:09:25 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA16686 for ; Wed, 4 Sep 1996 20:09:20 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA03386 (5.65c/IDA-1.5 for ); Wed, 4 Sep 1996 20:07:34 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id WAA10719; Wed, 4 Sep 1996 22:04:41 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Sep 1996 22:04:56 -0500 To: dg@root.com From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> I cannot do "what I want". > Please realize that I'm sure it would be of significant benefit to you > personally and perhaps to some larger set of people, but as always, we have to > look at the big picture and balance our resources to satisfy the largest > number of people with the effort that we expend. It has to be this way for > both practical and pragmatic reasons. Actually, I personally receive no value. I'm quite happy running "-stable" or "picking and choosing" things from the cvs tree. I offered to help solve a problem that keeps popping up and distracting you (collectively) from the things that you want to spend time doing. I happen to feel that improvements of this type in the long run are more important than the code improvements. Whether you like it or no, we have to "sell" FreeBSD. Making not only the code, but the organization, more user friendly will influence far more people than will the excellent quality of the internals which you already do well. > However...like Michael just suggested, nothing prevents you from setting up >such a framework for a "-recent" distribution. If you come up with a model >that works, we might even arrange for it to be replicated in various places >to increase the distribution potential. The key here is that you are (from >my perspective anyway) trying to force us to adopt some personal grand plan >of yours and even if it was a good idea, trying to get us to do more work >through coercion is entirely the wrong approach and you should expect your >efforts to fail. I have a different perspective. There IS a problem. Jordan, Terry, Nate, and I, and perhaps others, have discussed a possible solution. I offered to be the coordinator of the effort to move to something that will address the problem. I have even given a detailed description of the new scheme. This new scheme will buy absolutely nothing but additional headaches if you attempt to run it in parallel with the existing chaos. Even if it were implemented, it would take additional effort to build the critical user mass that makes it worthwhile. You would also have the "documentation" problem of explaining "how this is different from that". The other approach, which I advocate, is to bite a bullet here and there and make some changes that lay the groundwork for better improvements in the future. Since you, collectively, are unwilling to accept anything that an outsider does unless it is a completely implemented, tested and documented package, you will never, IMHO, solve the fundamental structural problems of your approach nor realize the values that can be reached in incremental steps. From owner-freebsd-current Wed Sep 4 20:09:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA16717 for current-outgoing; Wed, 4 Sep 1996 20:09:35 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA16710 for ; Wed, 4 Sep 1996 20:09:30 -0700 (PDT) Received: from root.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0uyUoi-0008suC; Wed, 4 Sep 96 20:09 PDT Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id TAA02038; Wed, 4 Sep 1996 19:34:35 -0700 (PDT) Message-Id: <199609050234.TAA02038@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: rkw@dataplex.net (Richard Wackerbarth), nate@mt.sri.com, current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Thu, 05 Sep 1996 11:15:32 +0930." <199609050145.LAA07943@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Wed, 04 Sep 1996 19:34:35 -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I cannot do "what I want". > >This doesn't follow from what you've just stated. The _only_ new element in >your masterplan is the creation of the -recent thread, which as a direct >derivative of -current, can be done by any site or sites currently >using any of the -current update mechanisms. With access to sup/CVSup/CTM >you can simulate reasonably accurately the master CVS repository from which >all changes would be flowing. Then you can implement the downstream >system(s) either with your own resources or with some volunteers. > >If your plan works, more will join the bandwagon. If it sinks, we don't go >down with you. It may or may not be obvious, but there is only one significant reason why we ("we" being the people who are responsible for the distribution of FreeBSD in its various forms) resist change. The simple fact it that we're already loaded to the limit of the amount of work that we can do, and thus the prospect of changing the current model to one that is even more complex than what we're doing now does not at all sound appealing. We don't have the time for this. It's arguable if the new scheme would even be of significant benefit. Please realize that I'm sure it would be of significant benefit to you personally and perhaps to some larger set of people, but as always, we have to look at the big picture and balance our resources to satisfy the largest number of people with the effort that we expend. It has to be this way for both practical and pragmatic reasons. However...like Michael just suggested, nothing prevents you from setting up such a framework for a "-recent" distribution. If you come up with a model that works, we might even arrange for it to be replicated in various places to increase the distribution potential. The key here is that you are (from my perspective anyway) trying to force us to adopt some personal grand plan of yours and even if it was a good idea, trying to get us to do more work through coercion is entirely the wrong approach and you should expect your efforts to fail. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Wed Sep 4 20:12:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA16881 for current-outgoing; Wed, 4 Sep 1996 20:12:43 -0700 (PDT) Received: from srv1-bsb.GNS.com.br ([200.239.56.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA16871 for ; Wed, 4 Sep 1996 20:12:32 -0700 (PDT) Received: (from mail@localhost) by srv1-bsb.GNS.com.br (8.7.5/8.7.5) id AAA12513; Thu, 5 Sep 1996 00:12:00 -0300 (EST) Received: from dl0113-bsb.gns.com.br(200.239.56.113) by srv1-bsb.GNS.com.br via smap (V1.3) id sma012265; Thu Sep 5 00:10:02 1996 Received: by DANIEL.sobral (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA0057; Wed, 04 Sep 96 23:20:11 +0300 Message-Id: <9609042020.AA0057@DANIEL.sobral> Date: Wed, 4 Sep 96 23:20:10 +0300 From: "Daniel C. Sobral" Subject: Re: current-digest V1 #579 To: current@freefall.freebsd.org Reply-To: e8917523@linf.unb.br In-Reply-To: <199609041435.HAA14142@freefall.freebsd.org> from "owner-current-digest@freefall.freebsd.org" at Sep 4 96 7:35 am X-Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.3 PL11] for OS/2 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: George Scott > Date: Wed, 04 Sep 1996 11:58:17 +1000 > Subject: Re: Latest Current build failure > > > Hell, the concept of "production level" doesn't even make sense when > > discussing what's essentially a live snapshot of the engineering > > team's working sources and, if anything, the real problem here is that > > the WRONG PEOPLE are running -current! > > I think that part of the problem might be that the name is a little bit > misleading. When I first started looking at FreeBSD and heard about CURRENT > I had an image in my mind of the current release, ie, what I later discovered > was called -RELEASE. I guess it's just psychological. If you are not "current" with FreeBSD, you're obviously outdated. Given the pressure society puts today on being, how should I put it?, "avant-guard", it's no wonder that people get frustrated being unable to be "current". -- Daniel C. Sobral (8-DCS) dcs@gns.com.br e8917523@linf.unb.br From owner-freebsd-current Wed Sep 4 20:16:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA16993 for current-outgoing; Wed, 4 Sep 1996 20:16:37 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA16988 for ; Wed, 4 Sep 1996 20:16:35 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id UAA05497; Wed, 4 Sep 1996 20:06:28 -0700 (PDT) To: Terry Lambert cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 18:22:23 PDT." <199609050122.SAA07805@phaeton.artisoft.com> Date: Wed, 04 Sep 1996 20:06:28 -0700 Message-ID: <5495.841892788@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > It seems to me that resolving to allow someone to implement something > with the results of the discussion would change that to 1-0 on their > relative ineffectiveness scores. Hell, just implementing something would raise the score on its own. :-) Jordan From owner-freebsd-current Wed Sep 4 20:32:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA17654 for current-outgoing; Wed, 4 Sep 1996 20:32:00 -0700 (PDT) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA17638 for ; Wed, 4 Sep 1996 20:31:49 -0700 (PDT) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id XAA17696; Wed, 4 Sep 1996 23:25:20 -0400 (EDT) From: Robin Cutshaw Message-Id: <199609050325.XAA17696@intercore.com> Subject: Re: XFree86 on Current To: matt@bdd.net (Matthew Stein) Date: Wed, 4 Sep 1996 23:25:16 -0400 (EDT) Cc: freebsd-current@freebsd.org, core@xfree86.org In-Reply-To: from "Matthew Stein" at Sep 4, 96 07:51:34 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > The current X312E binaries avialable on ftp.freebsd.org are now out of > date, and expire. Some of us require the betas, and can *almost* use the > new F binaries available on ftp.xfree86.org. > F has some problems. G will be out *very*, *very* soon. > I say almost, because is built with libc.so.2.2, which is no longer in > current. The X312E binaries in > ftp.freebsd.org:/pub/FreeBSD/XFree86/2.2-CURRENT/XF86312E worked fine, but > are out of date now. > > Are there plans to replace these binaries with ones that will run without > the compat21 options? Or, am I just missing something? No. We build against the latest release version, not against -current. That said, I'm building G against 2.2-960801-SNAP as we speak and will make them available if the rest of the XFree86 core team doesn't have a problem. robin (robin@XFree86.Org) -- ---- Robin Cutshaw internet: robin@interlabs.com Internet Labs, Inc. BellNet: 404-817-9787 "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-current Wed Sep 4 20:38:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA17915 for current-outgoing; Wed, 4 Sep 1996 20:38:09 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA17898 for ; Wed, 4 Sep 1996 20:37:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA08077; Wed, 4 Sep 1996 20:35:53 -0700 From: Terry Lambert Message-Id: <199609050335.UAA08077@phaeton.artisoft.com> Subject: Re: current-digest V1 #579 To: e8917523@linf.unb.br Date: Wed, 4 Sep 1996 20:35:53 -0700 (MST) Cc: current@freefall.freebsd.org In-Reply-To: <9609042020.AA0057@DANIEL.sobral> from "Daniel C. Sobral" at Sep 4, 96 11:20:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I guess it's just psychological. If you are not "current" with > FreeBSD, you're obviously outdated. Given the pressure society puts > today on being, how should I put it?, "avant-guard", it's no wonder > that people get frustrated being unable to be "current". Actually, if you do your development relative to anything other than -current, unless youare comitter, your patches will never be able to cleanly apply. Thus if you are a coder, there is a strong incentive to stay -current. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 20:51:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA18640 for current-outgoing; Wed, 4 Sep 1996 20:51:34 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA18634 for ; Wed, 4 Sep 1996 20:51:29 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA08103; Wed, 4 Sep 1996 20:47:46 -0700 From: Terry Lambert Message-Id: <199609050347.UAA08103@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: dg@root.com Date: Wed, 4 Sep 1996 20:47:46 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, rkw@dataplex.net, nate@mt.sri.com, current@FreeBSD.org In-Reply-To: <199609050234.TAA02038@root.com> from "David Greenman" at Sep 4, 96 07:34:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >If your plan works, more will join the bandwagon. If it sinks, we don't go > >down with you. > > It may or may not be obvious, but there is only one significant reason why > we ("we" being the people who are responsible for the distribution of FreeBSD > in its various forms) resist change. The simple fact it that we're already > loaded to the limit of the amount of work that we can do, and thus the > prospect of changing the current model to one that is even more complex than > what we're doing now does not at all sound appealing. We don't have the time > for this. It's arguable if the new scheme would even be of significant benefit. > Please realize that I'm sure it would be of significant benefit to you > personally and perhaps to some larger set of people, but as always, we have to > look at the big picture and balance our resources to satisfy the largest > number of people with the effort that we expend. It has to be this way for > both practical and pragmatic reasons. Where would nay thread be without its car analogy? 8-). Actually, it's a significant investment to move from your existing car (which is a 1974 Chevy Mailbu that gets 8 miles to the gallon) to the new Geo Storm (which gets 36 miles to the gallon). However, having moved, you free up resources which were otherwise being consumed to maintain the status quo. I think the gist of the discussion (the one I think I've been having, anyway 8-)) is intended to *offload* the burden from you, Jordan, and others, and to put the burden on the process. This is a fractal complexity issue. If it becomes overall more complex, but it becomes orthoganal at the same time, you can reduce your management overhead to only consider the top fractal dimension. The process, if built corectly, will force everything else to fall into line. This helps to solve your problem -- not adds to it. At the same time, it resolves some of the nagging issues that come up once in a while, as a side benefit -- the comparison of process to that of the Linux camp, for one. > However...like Michael just suggested, nothing prevents you from setting up > such a framework for a "-recent" distribution. If you come up with a model > that works, we might even arrange for it to be replicated in various places > to increase the distribution potential. The key here is that you are (from > my perspective anyway) trying to force us to adopt some personal grand plan > of yours and even if it was a good idea, trying to get us to do more work > through coercion is entirely the wrong approach and you should expect your > efforts to fail. I think he wants you to vet a process change, in the same way a comitter or core team memebr must vet code before it is checked in. Processes are ephemeral things which are whatever a group can agree they are. The anti-change inertia can function as a firebreak; but it can also function to help you shoot yourself in the foot. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 20:58:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA19057 for current-outgoing; Wed, 4 Sep 1996 20:58:50 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA19051 for ; Wed, 4 Sep 1996 20:58:46 -0700 (PDT) Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id XAA14360; Wed, 4 Sep 1996 23:57:12 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: jkh@time.cdrom.com (Jordan K. Hubbard), rkw@dataplex.net, current@FreeBSD.org From: "Gary Palmer" Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 19:32:54 PDT." <199609050232.TAA07941@phaeton.artisoft.com> Date: Wed, 04 Sep 1996 23:57:11 -0400 Message-ID: <14356.841895831@orion.webspan.net> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote in message ID <199609050232.TAA07941@phaeton.artisoft.com>: > That's sort of the point of having discussions in the first place: to > ask "what is the policy?" and keep asking until we get an answer other > than "there is none". Requirements: 1) it works 2) it keeps people happy, or even better, happier than they are now. 3) it eliminates futile debating of niggling details in public. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-current Wed Sep 4 21:00:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA19205 for current-outgoing; Wed, 4 Sep 1996 21:00:27 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA19199 for ; Wed, 4 Sep 1996 21:00:24 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id VAA18301 for ; Wed, 4 Sep 1996 21:00:22 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA08131; Wed, 4 Sep 1996 20:56:12 -0700 From: Terry Lambert Message-Id: <199609050356.UAA08131@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 4 Sep 1996 20:56:12 -0700 (MST) Cc: rkw@dataplex.net, nate@mt.sri.com, current@FreeBSD.org In-Reply-To: <5412.841891920@time.cdrom.com> from "Jordan K. Hubbard" at Sep 4, 96 07:52:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I've tried very hard to explain to Richard that things just can't work > the way he wants them to You have explained this several ways. What you haven't explained is what, in the nature of the universe, causes this to be try. You explain *what*, but you do not explain *why*. I think David's posting came closest to the mark; he explained that there is inertia which favors the status quo (what), and then he explained what he saw as the reasons for the intertia (why). It's now up to Richard to explain how his plan addresses the reasons for the inertia. The inertia itself is a reactive force that operates on stimuli and on underlying assumptions. If the underlying assumptions can be disarmed, then there is no reason for the stimuli to elicit the same reaction as it would if they were in force. > Man, after picking my jaw up off the floor, you can bet your ass I'd > look at it. If it was really good stuff, you'd probably see me > jumping up in down in -hackers about an hour later screaming "Joe > Hacker for president! Joe Hacker for God!" > > Guess we'll just have to wait until Joe Hacker shows up! :-) Joe Hacker will be more likely to present his credentials if you will define what "good stuff" is, other than a value judgement at the time you are presented with a fait accompli. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 21:18:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA19911 for current-outgoing; Wed, 4 Sep 1996 21:18:29 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA19899 for ; Wed, 4 Sep 1996 21:18:23 -0700 (PDT) Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id AAA16325; Thu, 5 Sep 1996 00:18:11 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: rkw@dataplex.net (Richard Wackerbarth) cc: dg@Root.COM, current@FreeBSD.org From: "Gary Palmer" Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 22:04:56 CDT." Date: Thu, 05 Sep 1996 00:18:10 -0400 Message-ID: <16322.841897090@orion.webspan.net> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth wrote in message ID : > Since you, collectively, are unwilling to accept anything that an outsider > does unless it is a completely implemented, tested and documented package, > you will never, IMHO, solve the fundamental structural problems of your > approach nor realize the values that can be reached in incremental steps. Richard, We do accept packages that are not completely tested or documented, but they have to EXIST first! We cannot commit vapourware to the CVS tree (despite the fact Microsoft seem to do it regularly). I think that there is this problem here. You say we don't accept your solutions to problem `x'. For everyone else in the universe, to date, to accept their solution to `x' we ask for code as we can discuss theory until we are blue in the face (and often do), but working code (or even semi-working code) is all that really matters to a voluntary project like ourselves. I think maybe if you had a track record of producing good results, we would accept proposed solution and give you the reins, but (to my memory at least) you are still a relative unknown. So there is (in my mind at least) a confidence level yet to be attained for us to accept this sort of solution. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-current Wed Sep 4 21:23:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA20133 for current-outgoing; Wed, 4 Sep 1996 21:23:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA20123 for ; Wed, 4 Sep 1996 21:23:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA08185; Wed, 4 Sep 1996 21:18:21 -0700 From: Terry Lambert Message-Id: <199609050418.VAA08185@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: dg@root.com Date: Wed, 4 Sep 1996 21:18:21 -0700 (MST) Cc: rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <199609050321.UAA02205@root.com> from "David Greenman" at Sep 4, 96 08:21:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >improvements. Whether you like it or no, we have to "sell" FreeBSD. Making > >not only the code, but the organization, more user friendly will influence > >far more people than will the excellent quality of the internals which you > >already do well. [ ... ] > >I have a different perspective. There IS a problem. Jordan, Terry, Nate, > >and I, and perhaps others, have discussed a possible solution. I offered to > >be the coordinator of the effort to move to something that will address the > >problem. > >I have even given a detailed description of the new scheme. > > I think you're looking at the problem with blinders on. Whether the sources > build or not is a _very_ small problem when compared with the larger issue of > whether or not the code works correctly. As I've already said, it's our policy > that the code should compile after a CVS commit. If it doesn't then this is > clearly a mistake and perhaps people should try harder to at least satisfy > this requirement. > > What you should be complaining about is not source tree build problems. The > real problems are with the proper operation of the code. This is a far bigger > problem - certainly more critical to the success of FreeBSD - and one that > doesn't have any easy solutions other than rigorous testing (which we do of > course, but can take weeks of time to show up certain problems). ...and we > have addressed this problem in the only way we reasonably can: it's why we do > releases. Look at it logically: 1) Inre: testing Posit: The ability to reliably compile current will increase the use of current Posit: Increased use implies increased testing Conclusion: It is possible to increase testing by increasing the the ability to reliably compile current 2) Inre: load on the core team Posit: Most "fires" posted about on the -current list are the result of failure of the tree to build as expected, for whatever reason Posit: The main reasons the tree fails to build as expected are "pilot error", "internal tree inconsistency", and "race conditions in the process of making the tree available" Posit: Most "fires" posted about on the -current list must be verified/refuted by an expenditure of effort, generally by a core team member Posit: The verification/refutation of a given "fire" constitutes "load" Conclusion: It is possible to reduce load on the core team by removing the possibility for "pilot error" in the build process, removing the possibility for "internal tree inconsistency" (either in the real tree, or in the exposed tree), and by closing the potential race windows. Pretty obviously, the only negative effect is "status quo is changed". I claim that the measurement system that calls this a negative effect is, itself, flawed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 21:30:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA20468 for current-outgoing; Wed, 4 Sep 1996 21:30:18 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA20462 for ; Wed, 4 Sep 1996 21:30:14 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA08210; Wed, 4 Sep 1996 21:27:51 -0700 From: Terry Lambert Message-Id: <199609050427.VAA08210@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: nate@mt.sri.com (Nate Williams) Date: Wed, 4 Sep 1996 21:27:50 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, current@freebsd.org In-Reply-To: <199609050405.WAA04202@rocky.mt.sri.com> from "Nate Williams" at Sep 4, 96 10:05:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Joe Hacker will be more likely to present his credentials if you will > > define what "good stuff" is, other than a value judgement at the time > > you are presented with a fait accompli. > > 'Good Stuff' - Something which provably works better than the status quo > which in the end doesn't require more work out of 'me'. The criteria "doesn't require more work out of 'me'" is a subjective value judgement. It's inherently impossible to provide a technical answer when a value judgement is involved, since subjective values can not be generalized or quantified. "I can't tell you wht pornography is, but I know it when I see it" is not a sufficient answer on which to base a policy decision. > My grandparents have a poster at their house that is appropriate: > > "A single good deed is better than the grandest of good intentions." > > Translation: > > "An implemented idea is better than the grandest of good proposed solutions." How about *implementing* a policy, then, so Richard can have a non-subjective ruler with which he can measure his design, and correct it where it is wanting, instead of wasting time building a football stadium only to find out the team he is building it for is the Dodgers (ie: "build a stadium" is not a sufficiently qualified directive). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 21:41:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA21067 for current-outgoing; Wed, 4 Sep 1996 21:41:59 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA21062; Wed, 4 Sep 1996 21:41:51 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA08242; Wed, 4 Sep 1996 21:40:16 -0700 From: Terry Lambert Message-Id: <199609050440.VAA08242@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: gpalmer@FreeBSD.org (Gary Palmer) Date: Wed, 4 Sep 1996 21:40:15 -0700 (MST) Cc: rkw@dataplex.net, dg@Root.COM, current@FreeBSD.org In-Reply-To: <16322.841897090@orion.webspan.net> from "Gary Palmer" at Sep 5, 96 00:18:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I think that there is this problem here. You say we don't accept your > solutions to problem `x'. For everyone else in the universe, to date, > to accept their solution to `x' we ask for code as we can discuss > theory until we are blue in the face (and often do), but working code > (or even semi-working code) is all that really matters to a voluntary > project like ourselves. Once again: Richard wants you to accept (or help correct) his definition of "problem x". Then he wants to have a definition of "acceptable soloutions to the class of problems of which "problem x" is a member. This will allow him to code a soloution which, if you do not backtrack on your word, will be considered solely on it's ability to solve the problem, instea of on its implementation details. > I think maybe if you had a track record of producing good results, we > would accept proposed solution and give you the reins, but (to my > memory at least) you are still a relative unknown. So there is (in my > mind at least) a confidence level yet to be attained for us to accept > this sort of solution. Richard does not want the reins. He wants a roadmap so that he can go a little ways down the road without having to have someone come back later and say "that's not the road to Topeka!"... and Richard has already expended the effort to build Topeka at the end of that road. A general comment: It is unprofessional to assume someone is "unprofessional unless proven otherwise". The correct default protocol for optimize effective progress is to assume the other person is acting from a position of good faith. To do otherwise, and require a "buy in" is cronyism. I suggest the book "The Evolution of Cooperation", and Douglas Hofstader's treatment of "The Prisoners Dilemma"; specifically, the strategy called "modified tit-for-tat with forgiveness starting from an expectation of good faith". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 21:45:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA21170 for current-outgoing; Wed, 4 Sep 1996 21:45:32 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA21159; Wed, 4 Sep 1996 21:45:20 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA08255; Wed, 4 Sep 1996 21:43:43 -0700 From: Terry Lambert Message-Id: <199609050443.VAA08255@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: gpalmer@FreeBSD.org (Gary Palmer) Date: Wed, 4 Sep 1996 21:43:43 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <14356.841895831@orion.webspan.net> from "Gary Palmer" at Sep 4, 96 11:57:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Terry Lambert wrote in message ID > <199609050232.TAA07941@phaeton.artisoft.com>: > > That's sort of the point of having discussions in the first place: to > > ask "what is the policy?" and keep asking until we get an answer other > > than "there is none". > > Requirements: > > 1) it works > > 2) it keeps people happy, or even better, happier than they are now. > > 3) it eliminates futile debating of niggling details in public. 1) Subjective 2) Also subjective, and prone to measurement bias: happy people do not complain, ipso facto it is impossible to measure the "net happiness" a change will cause. 3) Any soloution implemented with the consent of the discussion participants meets this criteria. Do you grant your consent? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 4 22:21:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA22556 for current-outgoing; Wed, 4 Sep 1996 22:21:39 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA22551 for ; Wed, 4 Sep 1996 22:21:36 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id HAA23014; Thu, 5 Sep 1996 07:21:29 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA09283; Thu, 5 Sep 1996 07:21:28 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id GAA25831; Thu, 5 Sep 1996 06:51:35 +0200 (MET DST) From: J Wunsch Message-Id: <199609050451.GAA25831@uriah.heep.sax.de> Subject: Re: booting from SCSI problem To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 5 Sep 1996 06:51:34 +0200 (MET DST) Cc: g.muesch@stochastik.rwth-aachen.de (Guido Muesch) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199609042043.VAA03670@saturn.stochastik.rwth-aachen.de> from Guido Muesch at "Sep 4, 96 09:43:21 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Guido Muesch wrote: > I have two hard drives: One IDE (170MB DOS) and one SCSI (2GB with FreeBSD > in first slice) and booteasy installed in both MBRs. Old bootblocks: hd(1,a)/kernel New bootblocks: 1:sd(0,a)/kernel In -current, ``nextboot'' is supposed to automatically remember these settings. However, a friend of mine didn't have much luck in trying to use it. (Sorry Julian, i couldn't convince him to send a report about his problems, and i'm in time pressure myself right now.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Sep 4 22:22:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA22577 for current-outgoing; Wed, 4 Sep 1996 22:22:39 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA22571 for ; Wed, 4 Sep 1996 22:22:30 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id OAA09648; Thu, 5 Sep 1996 14:52:13 +0930 From: Michael Smith Message-Id: <199609050522.OAA09648@genesis.atrad.adelaide.edu.au> Subject: Re: Latest Current build failure To: rkw@dataplex.net (Richard Wackerbarth) Date: Thu, 5 Sep 1996 14:52:13 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, nate@mt.sri.com, current@freebsd.org In-Reply-To: from "Richard Wackerbarth" at Sep 4, 96 09:25:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth stands accused of saying: > > > >You don't have to 'modify' anything. If you want to see your plans in > >action, you should be setting up the service _in_parallel_. Just because > >you can't convert the whole community to your One True Policy instantly > >is no reason not to try it. > > Here I disagree. Unless, by policy, we eliminate the source of the problem, > we have gained nothing. Further, we neither have the collective resources, > nor avoid the confusion factor by adding another basically redundant > distribution. This paragraph is just totally beyond context, let alone content. You speak of "eliminating" some problem. I see lots of problems. None of them are going to be "eliminated" by policy changes. They may be mitigated by technology changes which will bring implicit policy with them. The FreeBSD project is (read Terry again) not policy-driven but technology-driven. Given human nature, reality and the current limits of the technology, policy simply gives named form to reality. Further, if you think that the "-recent" distribution that you're touting is redundant, why on earth do you bother? > Actually there is a minor change in that the mirrors would, in my scheme be > synced so that you could shift from one to another. *shrug* This can probably be done now. Is it important? Maybe - what is preventing you from proposing a technique for syncing them? This sounds like an excellent idea, but not one that impacts me terribly. > >Huh? Where is your test-build server? Where are your publically-released > >scripts that run 'make bootstrap;make world', and if the build fails > >restore the _entire_system_ to a previously-saved checkpoint state. > > You missed the point that that is a second phase. The users gain some from > the synchronization, but this step also prepares them for the next one. You are saying "I cannot do what I want", and then you are saying "the only things that I actually want to do are the second phase". You make no sense. > >> I cannot do "what I want". > > > >This doesn't follow from what you've just stated. The _only_ new element in > >your masterplan is the creation of the -recent thread, which as a direct > >derivative of -current, can be done by any site or sites currently > >using any of the -current update mechanisms. With access to sup/CVSup/CTM > >you can simulate reasonably accurately the master CVS repository from which > >all changes would be flowing. Then you can implement the downstream > >system(s) either with your own resources or with some volunteers. > > Poppycock! This works "by inspection". We simply have to get the > distribution sites to standardize on an already proven mechanism. "We" don't "have to" do anything. You, on the other hand, could do with trying to make your statements mean something. So far, I read you as saying : - You cannot use sup/ctm/whatever as a top-level feed to simulate the distribution process. (false) - Something works "by inspection". (What? What does "bu inspection" mean anyway?) - It is necessary to bring all of the FreeBSD distribution process under your heel. (Possibly; but not a move likely to endear you to anyone) > As for the "validation" stuff, you left out the migration path that said > that we could start by assuming that each release was OK. And now you aren't bothering to understand _me_. You can't "assume" that any state is OK. You have to take an arbitrary state, being the latest poll of the repository, and determine whether it is or is not OK. The validation process is the fundamental basis of the decision as to whether to hiccup -recent further along. (and as JDP saliently observed, this still won't help those who are Born to Lose, as they will be able to screw themselves just as well attempting to build a tree that wasn't validated on their particular system under their exact circumstances.) > The real thing that is different is that "current" would no longer exist in > quite the same way as a bunch of unsynchronized snapshots. If you are suggesting that I should not be able to track, as close as I care to chose, the bleeding edge, then you can take your neat ideas, fold them until they are all sharp corners, and attempt to pack your appendix with them from the wrong end. The current distribution system, as can be demonstrably shown, works quite well. If you want to add extra functionality to make life all the easier for those that find it difficult to deal with, that's wonderful. Suggesting, however, that your Grand Plan is so much better that it must replace everything is not going to convince anyone. > I cannot really give you anything of value until I have reworked the > distribution system. This is just total shite. I cannot possibly see you here with anything other than a childish expression insisting that nobody can play until _after_ they give you all the toys and you decide who gets what. You can produce, in pilot, a _complete_duplicate_ of the _entire_ distribution system, using exactly the same input as the real thing has. This is available to you _right_now_. > There is the "critical mass" question. Without the "help" of the > organization, this thing will never fly. The "organisation" is more than willing to help. You have Jordan offering you a blank cheque for hardware and disk space, you have the undivided attention of most of the build-process gurus and all of the core team, you almost certainly have a number of people who are more than willing to spend time helping you, and indubitably a larger number of people who, when presented with your implementation, will offer criticisms that you can benefit from. Once your system is working in pilot, you will attract people to it, and it will then develop the "critical mass" necessary to be adopted. You can't apply for a "critical mass" grant though - you have to attract it all by yourself. Yet what do you do? You stand around and whine; rapidly convincing all of us that your wonderful new build/distribution/whatever system is about as realised and likely as JMJ's all-singing tape driver. > I am unwilling to tackle such a major project by myself without official > approval. It is a case of shooting at a target that moves faster than I > can. Uhh. This point was dealt with over a week ago, and I am amazed that someone of your self-professed "professionalism" cannot possibly comprehend the response that you were given. > I've tried to explain it. All I get in reply is "You have to complete it > and show me before I will discuss it" Are you familiar with the term "pilot project"? You have been given carte blanche to go ahead with the pilot, and your current unwillingness is telling those who might be considered the project reviewers that your proposed project is no more than a vehicle for your vanity and self-importance. The only obstacles in your path are the ones that you are imagining for yourself; there are plenty of unkind conclusions that could be drawn from this, but it's probably better to be generous and just assume that you're thick. Prove Us Wrong. Please? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Sep 4 22:32:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA22842 for current-outgoing; Wed, 4 Sep 1996 22:32:07 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA22798 for ; Wed, 4 Sep 1996 22:32:00 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA09729; Thu, 5 Sep 1996 15:01:20 +0930 From: Michael Smith Message-Id: <199609050531.PAA09729@genesis.atrad.adelaide.edu.au> Subject: Re: Latest Current build failure To: rkw@dataplex.net (Richard Wackerbarth) Date: Thu, 5 Sep 1996 15:01:20 +0930 (CST) Cc: dg@Root.COM, current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Sep 4, 96 10:04:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth stands accused of saying: > > This new scheme will buy absolutely nothing but additional headaches if you > attempt to run it in parallel with the existing chaos. Even if it were > implemented, it would take additional effort to build the critical user > mass that makes it worthwhile. You would also have the "documentation" > problem of explaining "how this is different from that". As I see it, this is the critical difference of opinion around which all contention revolves. You put your point succinctly (for once 8); let me try to put the opposing side : The new scheme will have implementation problems, which simply due to the number of people involved will be _astronomical_. Running the two in parallel will allow the affected parties to chose their own time and means of cutover, taking the strain off considerably, and leaving a convenient fallback should the new system hiccup while it is being sorted out. You _cannot_ expect instant results with a change such as you are proposing. The documentation and "critical mass" issues are costs that would simply have to be borne - the alternatives are absolutely impalatable, and it is in refusing to address this fact that you are falling foul of semi-popular opinion. > Since you, collectively, are unwilling to accept anything that an outsider > does unless it is a completely implemented, tested and documented package, > you will never, IMHO, solve the fundamental structural problems of your > approach nor realize the values that can be reached in incremental steps. Here you are showing signs of hysteria. That's Bad. 8( A simple demonstration along the lines of "here, try this", is what's needed. So far you've insisted on acceptance before the fact, which is something that's patently unrealistic. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Sep 4 23:44:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26004 for current-outgoing; Wed, 4 Sep 1996 23:44:06 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA25948 for ; Wed, 4 Sep 1996 23:44:02 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA04202; Wed, 4 Sep 1996 22:05:28 -0600 (MDT) Date: Wed, 4 Sep 1996 22:05:28 -0600 (MDT) Message-Id: <199609050405.WAA04202@rocky.mt.sri.com> From: Nate Williams To: Terry Lambert Cc: jkh@time.cdrom.com (Jordan K. Hubbard), current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <199609050356.UAA08131@phaeton.artisoft.com> References: <5412.841891920@time.cdrom.com> <199609050356.UAA08131@phaeton.artisoft.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Whee, I'm going on a business trip for the next two weeks, so you can be sure I won't be involved in this any longer. :) ] > Joe Hacker will be more likely to present his credentials if you will > define what "good stuff" is, other than a value judgement at the time > you are presented with a fait accompli. 'Good Stuff' - Something which provably works better than the status quo which in the end doesn't require more work out of 'me'. 'Wasted Time' - Spending time arguing and discussing the merits of something which 'would' be better than the status quo if it were implemented, but the process of making it better will require significant amount of work out of 'me'. My grandparents have a poster at their house that is appropriate: "A single good deed is better than the grandest of good intentions." Translation: "An implemented idea is better than the grandest of good proposed solutions." Nate From owner-freebsd-current Wed Sep 4 23:44:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26033 for current-outgoing; Wed, 4 Sep 1996 23:44:19 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA26023 for ; Wed, 4 Sep 1996 23:44:15 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id VAA03865; Wed, 4 Sep 1996 21:17:00 -0600 (MDT) Date: Wed, 4 Sep 1996 21:17:00 -0600 (MDT) Message-Id: <199609050317.VAA03865@rocky.mt.sri.com> From: Nate Williams To: "Jordan K. Hubbard" Cc: rkw@dataplex.net (Richard Wackerbarth), Nate Williams , current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <5412.841891920@time.cdrom.com> References: <5412.841891920@time.cdrom.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In case someone else should want to try this, I can only offer this > advice: Design and build a prototype, show it off to everyone, we'll > go from there. Case in point. SUP is a 'good' distribution tool. However, we all admit that it had flaws. Enter John Polstra. Following the *exact* procedure above, he implemented CVSup, tested it, and then presented it to Jordan and a few other developers. Jaws dropped. CVSup *worked* (mostly). More debug time, bugs fixed, time elapsed and now CVSup is the 'preferred' distribution mechanism for developers, not because John convinced everyone how bad SUP was (we all know it's problems), but how much *better* CVSup was. John Polstra for president, John Polstra is a minor-deity. :) Nate From owner-freebsd-current Wed Sep 4 23:44:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26070 for current-outgoing; Wed, 4 Sep 1996 23:44:23 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA26046 for ; Wed, 4 Sep 1996 23:44:20 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA02797; Wed, 4 Sep 1996 16:03:54 -0600 (MDT) Date: Wed, 4 Sep 1996 16:03:54 -0600 (MDT) Message-Id: <199609042203.QAA02797@rocky.mt.sri.com> From: Nate Williams To: rkw@dataplex.net (Richard Wackerbarth) Cc: Nate Williams , current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: References: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Not in this case. This involves a policy change for the distribution of FreeBSD. > THere is no way that I can modify the distribution channels without the > "blessing" of the 'core'. > > What I propose is to have three tiers of distribution. > > At the top, we have those who either have direct access to the master tree > or are willing to live with CVSup'ed images taken from it. Which we have now. > At the next level, we have frequent snapshots of the tree. These are > clocked by the ctm-cvs generator (every 6 hours, I believe). I would have > the sup mirrors use this as their distributable product. Which we have now, except that the sup mirrors are synchronized and the code they have is based on whenver they last updated the tree. Since the 'frequent' snapshots of the tree are just as likely to give the user 'bogus' (uncompilable, unbuildable, crashable) code as the previous method there is no reason to force the mirror sites to use CTM. Note, having a 'standard' distribution directory would be a 'good thing', but it's hard to enforce, even with 'core' apporval since every mirror site is governed by it's own rules. > The third level would be the "current" (or as someone said, "recent") tree. > It would also be synced to the above mentioned distributions. However, the > distribution can be delayed or skipped until some verfication of the > "buildability" has been established. This can still be done, and I volunteer you to do it. *grin* You can be the 'cookie-man' who keeps a virgin copy of the tree, and when it's buildable you can claim it's the next candidate for 'recent'. Then, all of the 'mirrors' can snarf it from you. As Jordan already stated, WC doesn't have the resources to do it, and since you're so interested in making this work you're the most qualified site to start this. You'll need to get co-operation from the 'mirror' sites, and while you're communicating with them you may want to fix the 'distribution' problem above. I'm pretty sure 'core' wouldn't mind you doing this. Do any of the core members have any problem with Richard being the 'cookie-man', and organizing the mirror sites? Be careful not to impose too much 'policy for the sake of policy' on the sites. Forcing them to use CTM just because you like isn't a justifiable position, since the 'cookied-tree' would only be updated when a new 'recent' tree was OK'd by you, they could choose to get the bits however they best feel is good, and distribute them in the same manner. Nate From owner-freebsd-current Wed Sep 4 23:44:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26084 for current-outgoing; Wed, 4 Sep 1996 23:44:26 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA26065 for ; Wed, 4 Sep 1996 23:44:22 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA01487; Wed, 4 Sep 1996 12:58:29 -0600 (MDT) Date: Wed, 4 Sep 1996 12:58:29 -0600 (MDT) Message-Id: <199609041858.MAA01487@rocky.mt.sri.com> From: Nate Williams To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <199609041852.LAA07039@phaeton.artisoft.com> References: <199609041739.LAA00876@rocky.mt.sri.com> <199609041852.LAA07039@phaeton.artisoft.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > [ One more time... ] > > > This assumes that the writer lock is held over the build process; if it > > > were a nightly build run by cron on another box, then it would work as > > > well as the engineer's personal box. > > > > Writer lock won't solve any problems experienced in FreeBSD. It's been > > discussed to death. It's a solution waiting for a problem that doesn't > > exist. The problem doesn't exist in FreeBSD. Quit wasting everyones > > time and mailboxes with your solution to a non-existant problem. > > It solves a problem in the suggested replacement for the existing system. No, it doesn't. As has been discussed to death in the past, it solves *NO* problems in the past or present that can be solved. The *problem* is a human problem that can't be solved adequately using a computer. It needs human intervention (ala. Jordan's cookies). No 'locking' protocol within CVS will solve the problem, as the problem exists outside the scope of the version control software. 'Nuff said, you can continue to waste both my time and others, but it will be ignored. Nate From owner-freebsd-current Wed Sep 4 23:44:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26105 for current-outgoing; Wed, 4 Sep 1996 23:44:29 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA26083 for ; Wed, 4 Sep 1996 23:44:24 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA01512; Wed, 4 Sep 1996 13:04:25 -0600 (MDT) Date: Wed, 4 Sep 1996 13:04:25 -0600 (MDT) Message-Id: <199609041904.NAA01512@rocky.mt.sri.com> From: Nate Williams To: Terry Lambert Cc: rkw@dataplex.net (Richard Wackerbarth), current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <199609041757.KAA06834@phaeton.artisoft.com> References: <199609041757.KAA06834@phaeton.artisoft.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >Actually, you could seperate the process using a covert channel for the > > >checkout for the build server: > > > > > >2) copy active cvs tree on repository to statis cvs tree on > > > build server > > >5) copy successfully test-built static cvs tree on build server > > > to distribution cvs tree on distribution server (could be > > > the same machine, the repository, or could be a third machine) > > > > How can you tell the difference between a copy-time inconsistency that > results from a copy interleaving with a checkin process, as opposed > to an artifact in the cvs tree itself causing the inconsistency? In my experience, 'copy-time' inconsistancies 'simply don't happen'. I've been grabbing the CVS tree via SUP/CVSup since day one, and I can count on *one* hand the # of times I've had problems with the 'copy' I've gotten that's been busted because of a checkin in progress. As stated, it's simply not a problem worth messing with. (BTW, early versions of CVS used a single 'write-lock' scheme, but after testing it was considered overkill hence the 'new' scheme which used directory-lock schemes.) A recent discussion of this point went on in devel-cvs. Nate From owner-freebsd-current Wed Sep 4 23:44:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26126 for current-outgoing; Wed, 4 Sep 1996 23:44:31 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA26098 for ; Wed, 4 Sep 1996 23:44:27 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA00876; Wed, 4 Sep 1996 11:39:13 -0600 (MDT) Date: Wed, 4 Sep 1996 11:39:13 -0600 (MDT) Message-Id: <199609041739.LAA00876@rocky.mt.sri.com> From: Nate Williams To: Terry Lambert Cc: current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: <199609041634.JAA06605@phaeton.artisoft.com> References: <10860.841793798@time.cdrom.com> <199609041634.JAA06605@phaeton.artisoft.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ One more time... ] > This assumes that the writer lock is held over the build process; if it > were a nightly build run by cron on another box, then it would work as > well as the engineer's personal box. Writer lock won't solve any problems experienced in FreeBSD. It's been discussed to death. It's a solution waiting for a problem that doesn't exist. The problem doesn't exist in FreeBSD. Quit wasting everyones time and mailboxes with your solution to a non-existant problem. Nate From owner-freebsd-current Thu Sep 5 00:25:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA27886 for current-outgoing; Thu, 5 Sep 1996 00:25:36 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA27881; Thu, 5 Sep 1996 00:25:33 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id IAA00572; Thu, 5 Sep 1996 08:20:10 +0200 (MET DST) To: rkw@dataplex.net (Richard Wackerbarth) cc: Nate Williams , current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 16:50:00 CDT." Date: Thu, 05 Sep 1996 08:20:09 +0200 Message-ID: <570.841904409@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message , Richard Wackerbarth writes: >Nate Williams writes: > >>I think you give too much 'power' to the 'powers that be'. You're >>completely free to do anything you want. But, *FIRST* of all show a >>working prototype and *THEN* expect to be heralded as the hero. >> >>Put the cart before the horse, not the other way around. > >Not in this case. This involves a policy change for the distribution of FreeBS >D. >THere is no way that I can modify the distribution channels without the >"blessing" of the 'core'. You can implement and distribute the sources any way you want. The operative word here is "modify the distribution channels", how about you "augment the distribution channels" instead ? Do the same as I did when I made CTM: implement it, announce it, and if sufficient people join the band, you have a parade. I had no guarantees that CTM would be a success, be approved or anything else, I invested the time and I was lucky: it paid of. A lot of things I have spent time on in FreeBSD didn't. That's life. Rough concensus & working code, remember ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Sep 5 00:25:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA27905 for current-outgoing; Thu, 5 Sep 1996 00:25:40 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA27893; Thu, 5 Sep 1996 00:25:37 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id IAA00546; Thu, 5 Sep 1996 08:15:10 +0200 (MET DST) To: Terry Lambert cc: jkh@time.cdrom.com (Jordan K. Hubbard), rkw@dataplex.net, current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 13:28:20 PDT." <199609042028.NAA07260@phaeton.artisoft.com> Date: Thu, 05 Sep 1996 08:15:10 +0200 Message-ID: <544.841904110@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609042028.NAA07260@phaeton.artisoft.com>, Terry Lambert writes: >> I think I'm coming around to the best "solution" of all to this, at >> least from my personal perspective, and that's to do nothing and leave >> -current exactly as it is. >> >> I'm tired out just talking about it now. :-) > >Be prepared to revisit this discussion every 3-4 months, as we have >for several years now, then, for the same reasons: tabling an issue >does not resolve it. > Just like raising it every 3-4 months doesn't make it valid. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Sep 5 04:13:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA06641 for current-outgoing; Thu, 5 Sep 1996 04:13:20 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA06627 for ; Thu, 5 Sep 1996 04:13:15 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id MAA08981; Thu, 5 Sep 1996 12:12:24 +0100 Date: Thu, 5 Sep 1996 12:12:23 +0100 (BST) From: Doug Rabson To: Robin Cutshaw cc: current@freebsd.org Subject: Re: nfs related panic In-Reply-To: <199609042146.RAA16282@intercore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 4 Sep 1996, Robin Cutshaw wrote: > > Running 2.2-960801-SNAP or current-smp with 1 or 2 cpu's active I get: > > panic : ufs_ihashget:recursive lock not expected -- pid 155 > > when running two or more nfs clients off of this box as a server (and > building XFree86 312G remotely). Changing the number of nfsd's running > had no effect. > > Fixed in -current? There is a bug in the NFSv3 server. Try this patch: Index: nfs_serv.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v retrieving revision 1.30 diff -c -r1.30 nfs_serv.c *** nfs_serv.c 1996/06/08 12:16:26 1.30 --- nfs_serv.c 1996/09/05 11:11:28 *************** *** 2919,2924 **** --- 2919,2925 ---- nfsm_srvpostop_attr(getret, &at); return (0); } + vput(nvp); dirlen = len = NFSX_V3POSTOPATTR + NFSX_V3COOKIEVERF + 2 * NFSX_UNSIGNED; nfsm_reply(cnt); -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-current Thu Sep 5 05:07:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA08293 for current-outgoing; Thu, 5 Sep 1996 05:07:39 -0700 (PDT) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA08278 for ; Thu, 5 Sep 1996 05:07:35 -0700 (PDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id NAA20756 for ; Thu, 5 Sep 1996 13:05:10 +0100 Received: from tees.elsevier.co.uk (actually host tees) by snowdon with SMTP (PP); Thu, 5 Sep 1996 13:06:39 +0100 Received: (from dpr@localhost) by tees.elsevier.co.uk (8.6.13/8.6.12) id NAA07169; Thu, 5 Sep 1996 13:05:40 +0100 To: Nate Williams Cc: Terry Lambert , jkh@time.cdrom.com (Jordan K. Hubbard), current@freebsd.org Subject: Re: Latest Current build failure References: <5412.841891920@time.cdrom.com> <199609050356.UAA08131@phaeton.artisoft.com> <199609050405.WAA04202@rocky.mt.sri.com> From: Paul Richards Date: 05 Sep 1996 13:05:40 +0100 In-Reply-To: Nate Williams's message of Wed, 4 Sep 1996 22:05:28 -0600 (MDT) Message-ID: <57d901xj3f.fsf@elsevier.co.uk> Lines: 64 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > 'Good Stuff' - Something which provably works better than the status quo > which in the end doesn't require more work out of 'me'. > > 'Wasted Time' - Spending time arguing and discussing the merits of > something which 'would' be better than the status quo if > it were implemented, but the process of making it better > will require significant amount of work out of 'me'. > Hmm, I must admit that this thread has a certain amusement value. I suspect that hackers is the more appropriate forum but there *should* be a forum where hackers can just throw ideas around (even if they never get implemented, there's a learning curve in just discussing things that may lead to future development). Some people seem to feel they *have* to get involved in discussions and then complain that they never amount to anything. Hey guys, if you think this thread is wasting your time *STOP READING IT*, and let others discuss what they feel is important to them. Just maybe, after ideas have been thrown around enough someone will actually implement a prototype but at the moment this is all pointless since we're not discussing technical issues at all, the dialog goes something like Q: I think the Make system is broken because it's lacking XYZ. A: Fine, develop a prototype and we'll look at it. Q: Ok, but what's the spec going to be for the new design. A: Well, it has to be better than what we have now. Which is not a recipe for moving forward. I suggest that anyone who doesn't want to actually contribute to the design process just stop reading the thread and let Terry and Richard and anyone else interested talk about the design issues of a prototype and then perhaps we'll move forward. I think there's a problem on both sides, Richard's viewpoint is that there should be a concensus that the new prototype will be adopted. On the core side there's the viewpoint that they've enough to do without worrying about the problem and making commitments to adopt something that's not even down on paper yet. I suspect rather strongly that core would happily adopt a new mechanism if a group of people came up with a working prototype even if it required a fair amount of upheaveal (we've been through such major changes before with the VM system and the switch to 4.4 as obvious examples). When there's a clear advantage to the switch it's been made. The problem is that you're trying to win over the "powers that be" too early in the process. If the "powers that be" who are too busy just stop reading this thread and let those who are really interested discuss it to death then we may make some progress. Even if no code ever gets implemented at least some people's blood pressure will drop :-) -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155 From owner-freebsd-current Thu Sep 5 05:10:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA08540 for current-outgoing; Thu, 5 Sep 1996 05:10:22 -0700 (PDT) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA08529 for ; Thu, 5 Sep 1996 05:10:18 -0700 (PDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id NAA20801 for ; Thu, 5 Sep 1996 13:08:08 +0100 Received: from tees.elsevier.co.uk (actually host tees) by snowdon with SMTP (PP); Thu, 5 Sep 1996 13:10:00 +0100 Received: (from dpr@localhost) by tees.elsevier.co.uk (8.6.13/8.6.12) id NAA07171; Thu, 5 Sep 1996 13:09:06 +0100 To: Nate Williams Cc: "Jordan K. Hubbard" , rkw@dataplex.net (Richard Wackerbarth), current@freebsd.org Subject: Re: Latest Current build failure References: <5412.841891920@time.cdrom.com> <199609050317.VAA03865@rocky.mt.sri.com> From: Paul Richards Date: 05 Sep 1996 13:09:05 +0100 In-Reply-To: Nate Williams's message of Wed, 4 Sep 1996 21:17:00 -0600 (MDT) Message-ID: <57buflxixq.fsf@elsevier.co.uk> Lines: 26 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > Case in point. > > SUP is a 'good' distribution tool. However, we all admit that it had > flaws. Enter John Polstra. Following the *exact* procedure above, he > implemented CVSup, tested it, and then presented it to Jordan and a few > other developers. Not everyone likes to work this way. Some people are happy to spend their time working on their pet projects regardless of whether they ever get adopted or not. Others prefer to discuss proposals up front and see if there's interest in the idea before wasting their time on a solution that no-one's ever going to be interested in. The build system is so complex that it makes sense to me to get feedback from all possible users about what a "new" solution should look like. If people don't want to contribute to that discussion then they can just hit the delete key instead of trying to kill off the thread. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155 From owner-freebsd-current Thu Sep 5 05:33:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA10623 for current-outgoing; Thu, 5 Sep 1996 05:33:03 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA10605 for ; Thu, 5 Sep 1996 05:32:58 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id FAA06778; Thu, 5 Sep 1996 05:32:01 -0700 (PDT) To: Terry Lambert cc: rkw@dataplex.net, nate@mt.sri.com, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 20:56:12 PDT." <199609050356.UAA08131@phaeton.artisoft.com> Date: Thu, 05 Sep 1996 05:32:01 -0700 Message-ID: <6775.841926721@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Joe Hacker will be more likely to present his credentials if you will > define what "good stuff" is, other than a value judgement at the time > you are presented with a fait accompli. I think we'd all know it if we saw it. We're not talking about rocket science here, we're talking about a friggin' build system! Why is it that we can instrument an entirely new VM system without much more than 3 or 4 messages discussing ways and means, yet when it comes to adding something like a new flag to the "od" command then 500 messages are generated first, most of them highly impassioned. I for one am sick of this thread, and would far prefer to do the work *myself* at this point than continue this discussion. It'd be a more than reasonable trade-off. Jordan From owner-freebsd-current Thu Sep 5 05:35:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA11159 for current-outgoing; Thu, 5 Sep 1996 05:35:16 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA11152; Thu, 5 Sep 1996 05:35:13 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id FAA06800; Thu, 5 Sep 1996 05:35:13 -0700 (PDT) To: "Gary Palmer" cc: rkw@dataplex.net (Richard Wackerbarth), dg@Root.COM, current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Thu, 05 Sep 1996 00:18:10 EDT." <16322.841897090@orion.webspan.net> Date: Thu, 05 Sep 1996 05:35:13 -0700 Message-ID: <6797.841926913@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I think maybe if you had a track record of producing good results, we > would accept proposed solution and give you the reins, but (to my > memory at least) you are still a relative unknown. So there is (in my > mind at least) a confidence level yet to be attained for us to accept > this sort of solution. Very well said! Jordan From owner-freebsd-current Thu Sep 5 05:42:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA11712 for current-outgoing; Thu, 5 Sep 1996 05:42:50 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA11705 for ; Thu, 5 Sep 1996 05:42:47 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id FAA06822; Thu, 5 Sep 1996 05:42:01 -0700 (PDT) To: Terry Lambert Cc: current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Wed, 04 Sep 1996 21:40:15 PDT." <199609050440.VAA08242@phaeton.artisoft.com> Date: Thu, 05 Sep 1996 05:42:00 -0700 Message-ID: <6820.841927320@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Once again: Richard wants you to accept (or help correct) his definition > of "problem x". Then he wants to have a definition of "acceptable > soloutions to the class of problems of which "problem x" is a member. Yes, we know, can we please end this now? We are NOT approaching a resolution and the last 5 exchanges have shown, if anything, that we're getting farther away from one. Call it the status quo, call it inertia, call it a core team plot against you and Richard personally, I really don't care. Multiple people have told you the ONLY way in which change will work, you argue that this is impractical, fine. Let's agree to disagree and move on. You're not going to "win" this one by out-stubborning anyone. Jordan From owner-freebsd-current Thu Sep 5 05:51:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA12584 for current-outgoing; Thu, 5 Sep 1996 05:51:29 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA12523; Thu, 5 Sep 1996 05:51:17 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.7.5/8.6.9) with SMTP id NAA13305; Thu, 5 Sep 1996 13:52:02 +0100 (BST) Date: Thu, 5 Sep 1996 13:52:02 +0100 (BST) From: Developer Reply-To: Developer To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-chat@freebsd.org, freebsd-stable@freebsd.org Subject: Evaluation copies of FXHTML Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A number of evaluation copies of FXHTML are available from Fourth Level Developments to established web sites running under FreeBSD. Please apply, by emailing dev@flevel.co.uk, with the following information:- Organisation: Address: Server Name/IP Address: Contact Name: Tel Number: If you want more information about FXHTML please look at: http://www.flevel.co.uk/fxhtml/ Thanks for your time. From owner-freebsd-current Thu Sep 5 06:34:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA16598 for current-outgoing; Thu, 5 Sep 1996 06:34:23 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA16587 for ; Thu, 5 Sep 1996 06:34:15 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id IAA10440; Thu, 5 Sep 1996 08:32:46 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Sep 1996 08:32:46 -0500 To: Paul Richards From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I think there's a problem on both sides, Richard's viewpoint is that >there should be a concensus that the new prototype will be adopted. On >the core side there's the viewpoint that they've enough to do without >worrying about the problem and making commitments to adopt something >that's not even down on paper yet. No, I see it as a more fundamental difference. I have been led to believe that the only acceptable "prototype" has to include the ability to build a complete release distribution from scratch. In order to do THAT, I don't have to build a "prototype", I have to implement the entire system. Further, they are unwilling to agree to adopt any incremental steps toward that goal until I have demonstrated the final product. If I misunderstand their position, I wish that someone would state a MINIMAL set of things that I would have to demonstrate to satisfy the "prototype" requirement sufficiently to allow me to start removing the roadblocks that are throughout the system. I view this process analogous to the situation where Apple moved the MacOS from 24-bit to 32-bit addressing. In that case, they had to examine every line of code and remove ALL the 24-bit dependancies before they could actually throw the 32-bit switch. While Apple was making that change, coding on other project did not come to a screeching halt. It continued, adhearing to the newer specification which was adopted long before 32-bit addressing was demonstrated. From owner-freebsd-current Thu Sep 5 07:09:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA19455 for current-outgoing; Thu, 5 Sep 1996 07:09:30 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA19442 for ; Thu, 5 Sep 1996 07:09:25 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id HAA07207; Thu, 5 Sep 1996 07:07:53 -0700 (PDT) To: Paul Richards cc: Nate Williams , rkw@dataplex.net (Richard Wackerbarth), current@freebsd.org Subject: Re: Latest Current build failure In-reply-to: Your message of "05 Sep 1996 13:09:05 BST." <57buflxixq.fsf@elsevier.co.uk> Date: Thu, 05 Sep 1996 07:07:53 -0700 Message-ID: <7205.841932473@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Not everyone likes to work this way. Some people are happy to spend > their time working on their pet projects regardless of whether they > ever get adopted or not. Others prefer to discuss proposals up front > and see if there's interest in the idea before wasting their time on a > solution that no-one's ever going to be interested in. Perfectly true, and I'd never suggest that either approach is without its time and place. Now let's take it to the next stage, however, which is where many mistakes can be made if it's not handled right by the presenter or presentees. Let's say you're in the latter camp and you've thrown a proposal out for discussion. There are two "forks" down which the conversation may now travel: 1. Non-technical discussion. Here you have your rebuttals and commentary which doesn't really attempt to grapple with the core issue for which the proposal was originally raised at all. Things like "your proposal sucks and your mom dresses you strangely" or even "sounds good but you know, when it comes right down to it, I'd really almost rather watch the lawn grow than debate the details of an area of the system for which I've so little personal interest. Could you maybe just go implement it somewhere with a group of like-minded folks and leave me alone to work on my stuff? I'll take a look at whatever it is you came up with after it's finished and see if I can use it. Thanks." [Note: This is what so many would really *like* to say, but that's not very polite so they feel compelled to stretch the message out over 4-5 more carefully worded emails :)] A frequent and unfortunate side-effect of non-technical discussion is that it also rapidly leads to divergent threads, any intrinsic value of which is more or less irrelevant to those who joined a mailing list to read postings on a specific range of topics. 2. Technical discussion. All this generally requires is two or more enthusiastically (or at least motivatedly) interested parties to sustain a reasonably healthy point-and-rebuttal refinement process. Comments may be tossed in from time to time from those watching with interest on the sidelines, much as people shout encouragement to prize fighters in the boxing ring, and the whole process generally bears a lot of useful fruit. I enjoy these discussions, whether I'm participating or not. If the conversation has taken the second fork, then you're probably in good shape because you're an engineer and you can handle tech-talk all day without getting your nose too out of joint, though those who don't handle honest technical criticism well may be in for some rough waters. If the conversation takes the first fork, then you're already in rough water and you have to be pretty good if you want to avoid winding up on the rocks at this point. Finesse rather than brute force is the key there. Jordan From owner-freebsd-current Thu Sep 5 08:25:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA23912 for current-outgoing; Thu, 5 Sep 1996 08:25:12 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA23905 for ; Thu, 5 Sep 1996 08:25:08 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Thu, 05 Sep 1996 09:25:15 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 05 Sep 1996 08:35:25 -0600 From: Darren Davis To: matt@bdd.net, freebsd-current@freebsd.org Subject: XFree86 on Current - Reply Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> Matthew Stein 9/ 4 5:51pm >>> The current X312E binaries avialable on ftp.freebsd.org are now out of date, and expire. Some of us require the betas, and can *almost* use the new F binaries available on ftp.xfree86.org. I say almost, because is built with libc.so.2.2, which is no longer in current. The X312E binaries in ftp.freebsd.org:/pub/FreeBSD/XFree86/2.2-CURRENT/XF86312E worked fine, but are out of date now. Are there plans to replace these binaries with ones that will run without the compat21 options? Or, am I just missing something? >>> I just ran into this problem myself. Worse yet, I think the 3.1.2F binary may have problems since I am getting strange artifacts on the screen. I am interested in any solutions to this as well. Darren From owner-freebsd-current Thu Sep 5 08:26:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24010 for current-outgoing; Thu, 5 Sep 1996 08:26:41 -0700 (PDT) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA23996 for ; Thu, 5 Sep 1996 08:26:32 -0700 (PDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id QAA23471 for ; Thu, 5 Sep 1996 16:24:23 +0100 Received: from tees.elsevier.co.uk (actually host tees) by snowdon with SMTP (PP); Thu, 5 Sep 1996 16:26:15 +0100 Received: (from dpr@localhost) by tees.elsevier.co.uk (8.6.13/8.6.12) id QAA07212; Thu, 5 Sep 1996 16:25:20 +0100 To: rkw@dataplex.net (Richard Wackerbarth) Cc: Paul Richards , current@freebsd.org Subject: Re: Latest Current build failure References: From: Paul Richards Date: 05 Sep 1996 16:25:19 +0100 In-Reply-To: rkw@dataplex.net's message of Thu, 5 Sep 1996 08:32:46 -0500 Message-ID: <573f0xx9uo.fsf@elsevier.co.uk> Lines: 27 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk rkw@dataplex.net (Richard Wackerbarth) writes: > If I misunderstand their position, I wish that someone would state a > MINIMAL set of things that I would have to demonstrate to satisfy the > "prototype" requirement sufficiently to allow me to start removing the > roadblocks that are throughout the system. Umm, well can we start this thread again on a more technical basis. A good place to start would be to list the current shortcomings that people have with the current build system, work out a new design that solves them and finally come up with a solution that can be incrementally implemented so as not to make the system unusable at any stage. Each stage can then be prototyped and incorporated without requiring the all singing-all dancing implementation to be prototyped from scratch and all in one go. People may get a better idea of the purpose of the changes if they're done in stages, phased development is generally the best way I find to move people towards a goal that they don't appreciate from the outset. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155 From owner-freebsd-current Thu Sep 5 10:28:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03934 for current-outgoing; Thu, 5 Sep 1996 10:28:10 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA03898 for ; Thu, 5 Sep 1996 10:28:06 -0700 (PDT) Received: from applink.applink.net (root@applink.applink.net [206.149.40.1]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA19755 for ; Thu, 5 Sep 1996 09:46:10 -0700 (PDT) Received: from eagle.applink.net.applink.net (eagle.applink.net [206.149.40.181]) by applink.applink.net (8.6.12/8.6.12) with SMTP id LAA28888 for ; Thu, 5 Sep 1996 11:47:54 -0500 Message-Id: <199609051647.LAA28888@applink.applink.net> Comments: Authenticated sender is From: "Robert Garrett" To: current@freebsd.org Date: Thu, 5 Sep 1996 11:46:56 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: HELP: fds Priority: urgent X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk i need to know how to increase the maximum # of fd's...to at least 2048..... any help would be greatly appreciated... *********************************************** ** You only thought i did ** ** Now why's That? ** *********************************************** From owner-freebsd-current Thu Sep 5 10:29:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04096 for current-outgoing; Thu, 5 Sep 1996 10:29:52 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA04084 for ; Thu, 5 Sep 1996 10:29:50 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-139.ut.nl.ibm.net [139.92.42.139]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id JAA19642 ; Thu, 5 Sep 1996 09:28:00 -0700 (PDT) Received: (from root@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id SAA13786; Thu, 5 Sep 1996 18:27:42 +0200 (MET DST) Date: Thu, 5 Sep 1996 18:27:42 +0200 (MET DST) From: "Julian Stacey jhs@freebsd.org" Message-Id: <199609051627.SAA13786@vector.jhs.no_domain> To: John Polstra cc: current@freebsd.org Subject: Re: Latest Current build failure Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Wed, 04 Sep 1996 09:58:30 PDT." <199609041658.JAA18063@austin.polstra.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Reference: > From: John Polstra > > Julian Stacey : > > >CTM is asynchronous to net disturbances, so ideal for those with > > >poor net access, whereas cvsup requires a net in good condition. > > Justin Gibbs : > > This isn't true since CVSup is a streaming protocol instead of a > > synchronous like SUP. I know quite a few people who switched from > > CTM to CVSup that have poor links to the net. > > Justin is right. CVSup works very well under poor network conditions. Off topic for a moment, & meaning no one specificaly, but all of us, self included :-) .... It should not matter _who_ is right, or _who_ is wrong, it should matters _what_ is right, & _what_ is wrong. To attack, defend & build on ideas is constructive, To attack personalities advocating ideas, is divisive. An unskilled person can come up with an occasional great idea, just as a skilled person can come up with a daft idea. Ideas should be judged on merit, not by proponent & opponent personalities. FreeBSD lists far too often contain personality oriented conflicts, rather than idea oriented conflicts, which is a liability, & gives a bad image. --------- John, The key to this thread is Semantics ! What I said: poor net access What you said: under poor network conditions CVSup presumably functions well: With the _subset_ of poor network connectivity comprising: low speed & latency. With these advantages: streaming protocol, [& optimised for CVS transfer, I recall]. Subject to the constraints: - user is allowed to port, compile, & run cvsup on client host - client has room for source tree (presumed pre-requisite) - no firewall in the way - every node is up & running between client & server at the time when client wants to update (sup, cvsup,mirror,rdist etc all intrinsicaly rely on being able to establish an end to end virtual circuit) CTM performs well: With the subset of poor network connectivity comprising: Intermittent drop out of parts of net, end to end links either unavailable or appallingly slow. With these advantages: - mail can be forwarded to a local high bandwidth host while the recipient sleeps. - recipient can receive patches on a non FreeBSD mainframe, - CTMs can be carried home on a floppy - recipient needs no room on work machine for src/ or cvs/ - tcp/ip firewalls irrelevant, if mail works, it's enough. > That was one of the primary design goals. In fact, CVSup almost > certainly works better under adverse conditions than SMTP, which > delivers your CTM updates. But for anyone using a local proximity mail server: CTM merely requires your are connected for mail sometime or other most days. CVSup needs a permanent virtual circuit to be established end to end, between CVSup server & client, exactly when you want to update. CVSup cannot deliver more bandwidth than the ISP can deliver, which sometimes isnt very fast at all, when running protocols through the net to remote hosts, whereas the ISP can often offer to saturate the local modem, to 100% efficiency, if the CTM mail is stored localy. > Julian, have you even _tried_ CVSup?? I watch the server logs pretty > closely, and I don't recall seeing your name in them. Irrelevant. > But if you're going to comment publically on either CVSup or CTM, > you really ought to know what you're talking about first. Posted flame bait endangers a list's S/N ratio. I'll ignore it. > It's not in anybody's interest to start a "CVSup vs. CTM" war. They > each have advantages and disadvantages. People are welcome to use the > one that serves their needs the best. Agreed. I merely corrected Justin's incomplete assertion of where CVSup would be beneficial, by pointing to situations where no end to end protocol could cope, no matter how marvelous the protocol, & where one would have no choice but a store & forward mail method. (As before, Justin's understanding of `poor net connectivity' is presumably rather different to mine, hence our different conclusions.) Construe that as criticism of CVSup if you wish, but it's not my intention. >From what I've read CVSup seems attractive, & intend to use it, where appropriate. What some USA residents consider `poor net connectivity', some other net citizens would consider a luxury, and if you don't happen to know or remember how tenuous & bad `poor net connectivity' can get, consider yourself lucky :-) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Thu Sep 5 10:30:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04299 for current-outgoing; Thu, 5 Sep 1996 10:30:38 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA04273 for ; Thu, 5 Sep 1996 10:30:34 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA19629 for ; Thu, 5 Sep 1996 09:26:40 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA09349; Thu, 5 Sep 1996 09:22:58 -0700 From: Terry Lambert Message-Id: <199609051622.JAA09349@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 5 Sep 1996 09:22:58 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, rkw@dataplex.net, current@freebsd.org In-Reply-To: <544.841904110@critter.tfs.com> from "Poul-Henning Kamp" at Sep 5, 96 08:15:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Be prepared to revisit this discussion every 3-4 months, as we have > >for several years now, then, for the same reasons: tabling an issue > >does not resolve it. > > Just like raising it every 3-4 months doesn't make it valid. If it's invalid, then resolve it by proving it is invalid, and that the code does in fact build, or that the should, in fact, not be reasonably expected to build. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 5 10:31:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04519 for current-outgoing; Thu, 5 Sep 1996 10:31:18 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA04507; Thu, 5 Sep 1996 10:31:14 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-139.ut.nl.ibm.net [139.92.42.139]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id JAA19613 ; Thu, 5 Sep 1996 09:25:07 -0700 (PDT) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id VAA03250; Wed, 4 Sep 1996 21:52:54 +0200 (MET DST) Message-Id: <199609041952.VAA03250@vector.jhs.no_domain> To: "Justin T. Gibbs" Cc: current@freebsd.org Subject: Re: Latest Current build failure From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Wed, 04 Sep 1996 08:19:58 PDT." <199609041519.IAA16653@freefall.freebsd.org> Date: Wed, 04 Sep 1996 21:52:54 +0200 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: "Justin T. Gibbs" > Subject: Re: Latest Current build failure > Date: Wed, 04 Sep 1996 08:19:58 -0700 > Message-id: <199609041519.IAA16653@freefall.freebsd.org> > > >But CVSup is not the only appropriate solution ... > >We've had developers who produced useful code but were doomed to bad coms > >links. CTM is asynchronous to net disturbances, so ideal for those with > >poor net access, whereas cvsup requires a net in good condition. > > This isn't true since CVSup is a streaming protocol instead of a > synchronous like SUP. I know quite a few people who switched from > CTM to CVSup that have poor links to the net. Wrong. `Poor' net access does not just mean _slow_ access with long latency. `Poor' net access can also mean broken Internet relay hosts, with failing routers, ISPs that just drop out, modems that eraticaly don't answer, firewalls, intermittent intermediate hosts, etc. Mirror, cvsup, sup are all _comms_protocols_ that require a temporary end to end virtual circuit across the internet between server & client, without the link they won't work. CTM is _different_ it uses store & forward email, and survives despite net congestion or temporary total outage of net critical nodes. Email forwarding from a local ISP offering popserver will run full blast, whereas long distance links to servers may only be capable of delivering 100 bytes per second (regardless of streaming or not). CTM will work even if one can never establish a virtual end to end circuit Sure, CVSup's streaming protocol sounds marvellous for _increasing_ existing performance, _if_ you have the basic end to end functionality in place, but some people, self included, have had times when the local net works fine, but EG the transatlantic is _broken_ , not just slow, but broken. Now if my mail is buffered at a local nearby host, it doesn't matter if the transatlantic is temporarily dead, I can still update _now_, not keep dialing the modem & trying to establish a circuit via my ISP to the remote server, hoping all the intermediate net is intact at the time I want to use it. - CTM can be used via any machine on the planet that happens to be convenient & reliable for localy buffering your mail. - Sup CVSup Mirror et al need across-the-net access to a _server_ - There are many less Sup/CVSup/Mirror servers on the Internet, than there are local mail servers. Whether you know a few people that .... doesnt affect the technology. One could stay current with just uucp & 2400bd over wet string, fed from a string of relay hosts that crashed 20 times a day, if one used ctm + cvs. If you don't realise what `poor net access' can mean ... be grateful ! Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Thu Sep 5 11:05:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06380 for current-outgoing; Thu, 5 Sep 1996 11:05:27 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA06347 for ; Thu, 5 Sep 1996 11:05:10 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA09500; Thu, 5 Sep 1996 11:02:20 -0700 From: Terry Lambert Message-Id: <199609051802.LAA09500@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 5 Sep 1996 11:02:19 -0700 (MST) Cc: terry@lambert.org, rkw@dataplex.net, nate@mt.sri.com, current@FreeBSD.org In-Reply-To: <6775.841926721@time.cdrom.com> from "Jordan K. Hubbard" at Sep 5, 96 05:32:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Joe Hacker will be more likely to present his credentials if you will > > define what "good stuff" is, other than a value judgement at the time > > you are presented with a fait accompli. > > I think we'd all know it if we saw it. We're not talking about rocket > science here, we're talking about a friggin' build system! Why is it > that we can instrument an entirely new VM system without much more > than 3 or 4 messages discussing ways and means, yet when it comes to > adding something like a new flag to the "od" command then 500 messages > are generated first, most of them highly impassioned. Because the turf involved has already been staked out, and is not subject to a territory battle. But by the same token, I believe the people who have pre-assigned fiefdom's are also starting to feel a bit pidgeon-holed by the kindom-building. As I said in a previous posting, it is a two edged sword. The most damning thing about this process is that it does not scale well. If FreeBSD is to grow, the process must change. It was recently pointed out to me that if you send a patch to Linus, you get an email acknowledgement, and you are told either that it has been integrated, or why it won't be integrated. Similar patches in the same area of FreeBSD from the same person sat in a mailbox for 6 months, and were only acted upon when the problem became a critical annoyance. As a result, the person no longer attempts to contribute to FreeBSD... and he is one of the best kernel hackers I have seen in a long time: like me, it has been his professional career to hack kernels. He is not a rube. > I for one am sick of this thread, and would far prefer to do the work > *myself* at this point than continue this discussion. It'd be a more > than reasonable trade-off. For you. And this discussion is only a process symptom of a wider architectural problem. Refusing to address the architectural problem by refusing to discuss anything related to it is tantamount to "hiding" by closing your eyes. It is ineffective, and eventually it will become obvious that it doesn't work. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 5 12:42:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13260 for current-outgoing; Thu, 5 Sep 1996 12:42:13 -0700 (PDT) Received: from applink.applink.net (root@applink.applink.net [206.149.40.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA13254 for ; Thu, 5 Sep 1996 12:42:11 -0700 (PDT) Received: from eagle.applink.net.applink.net (eagle.applink.net [206.149.40.181]) by applink.applink.net (8.6.12/8.6.12) with SMTP id OAA30416 for ; Thu, 5 Sep 1996 14:44:17 -0500 Message-Id: <199609051944.OAA30416@applink.applink.net> Comments: Authenticated sender is From: "Robert Garrett" To: current@freebsd.org Date: Thu, 5 Sep 1996 14:43:17 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: A few comments: RE:current build failure Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I know i am breaking protocol after all i havent' read current for several months, but i still feel like there is an easy solution to the problem that seems to be perveating this discussion... 1. Change the name of current to reflect its a development source.... 2. weekly or so... produce a tree that builds so it can be tested... 3. rename the snapshots to somthing to reflect the idea that they are more stable in nature... well thats my idea now i will keep my mouth shut and go on about my business.. thanks for listening... From owner-freebsd-current Thu Sep 5 13:08:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA15086 for current-outgoing; Thu, 5 Sep 1996 13:08:10 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA15066 for ; Thu, 5 Sep 1996 13:07:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA09730; Thu, 5 Sep 1996 13:04:31 -0700 From: Terry Lambert Message-Id: <199609052004.NAA09730@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 5 Sep 1996 13:04:31 -0700 (MST) Cc: rkw@dataplex.net, msmith@atrad.adelaide.edu.au, nate@mt.sri.com, current@freebsd.org In-Reply-To: <199609050522.OAA09648@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Sep 5, 96 02:52:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > with them. The FreeBSD project is (read Terry again) not > policy-driven but technology-driven. Given human nature, reality and > the current limits of the technology, policy simply gives named form > to reality. Correction: policy gives constraints on future configurations of reality. The purpose of policy is not to say "here is how things are", but instead, "here is how things should be". If policy simply codifies existing practice, then you have accomplished nothing more than en entrenchment of the status quo. This would be an error. > You are saying "I cannot do what I want", and then you are saying "the only > things that I actually want to do are the second phase". You make no sense. Actually, this makes a lot of sense to me, probably because I've had a similar experience. 1) I want to work on advanced file systems design 2) To do that, I have to fix the framework 3) Fixing the framework without first doing the advanced file systems work yields no net benefit to people who don't also want to work on advanced file systems 4) Fixing the framework is opposed as "having no immediate benefit" It is a catch-22 that prevents me from working on advanced file systems design. > "We" don't "have to" do anything. You, on the other hand, could do with > trying to make your statements mean something. So far, I read you as > saying : > > - You cannot use sup/ctm/whatever as a top-level feed to simulate the > distribution process. > (false) Doing so artificially constrains the implementation. > - Something works "by inspection". > (What? What does "bu inspection" mean anyway?) "By inspection" is a term used in the hard sciences. The Physicists (my self included) refer to it as "IOTTMCO" -- "Intuitively Obvious To The Most Casual Observer". > - It is necessary to bring all of the FreeBSD distribution process under > your heel. > (Possibly; but not a move likely to endear you to anyone) I don't see where this is a requirement. > Born to Lose, as they will be able to screw themselves just as well > attempting to build a tree that wasn't validated on their particular system > under their exact circumstances.) Yet today, air bags are required as standard equipment to enable those "born to lose" to survive to wreak even greater havoc on our roadways... it *is* possible to build safety systems. > > The real thing that is different is that "current" would no longer exist in > > quite the same way as a bunch of unsynchronized snapshots. > > If you are suggesting that I should not be able to track, as close as I > care to chose, the bleeding edge, then you can take your neat ideas, fold > them until they are all sharp corners, and attempt to pack your appendix > with them from the wrong end. You should not be permitted to do so at the expense of everyone else (by your pursuit destableizing the tree for everyone else). The point is to build this requirement into the process whereby you interact with the tree. It is a safety system. It also protects you from the ill-executed changes of others. > The current distribution system, as can be demonstrably shown, works > quite well. And here is the crux of the disagreement. The statement is true when it is modified as: "the current distribution system works quite well for those people who are members of the core team, and passably well for those people who have direct commit priviledges". CVSup fixed a number of problems for people without direct commit priveledfes, but it certainly did not fix them all. Specifically, it did not fix the problems endemic to the lack of consistency enforcement (which would cause the tree to always be buildable), nor did it fix the problem of what to do with local branches to terminate them gracefully once the differences between them and the main line source have been integrated into the main line source. > You can produce, in pilot, a _complete_duplicate_ of the _entire_ > distribution system, using exactly the same input as the real thing > has. This is available to you _right_now_. But the name OpenBSD has already been taken by a similar pilot project in reaction to similar pressures within the NetBSD "core team" framework... what would he call such a duplicate distribution? I am only half-joking here. > The "organisation" is more than willing to help. The "organization", as an entity, will not work to reduce its own power any more than government will vote to reduce its own power. The problem isn't the organization, but it's intrenchment. It is a derivative (in the mathematical sense) in the same replationship momentum bears to kinetic energy. Richard wants, what is in effect, a decentralization of authority. The authority is not to be given to Richard, it is to be dispersed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 5 13:13:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA15418 for current-outgoing; Thu, 5 Sep 1996 13:13:54 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA15398 for ; Thu, 5 Sep 1996 13:13:38 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA09747; Thu, 5 Sep 1996 13:08:56 -0700 From: Terry Lambert Message-Id: <199609052008.NAA09747@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: p.richards@elsevier.co.uk (Paul Richards) Date: Thu, 5 Sep 1996 13:08:56 -0700 (MST) Cc: nate@mt.sri.com, terry@lambert.org, jkh@time.cdrom.com, current@FreeBSD.org In-Reply-To: <57d901xj3f.fsf@elsevier.co.uk> from "Paul Richards" at Sep 5, 96 01:05:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I hate to make this observation of what is supposed to be a concilitory posting, but... > If the "powers that be" who are too busy just stop reading this thread > and let those who are really interested discuss it to death then we > may make some progress. Even if no code ever gets implemented at least > some people's blood pressure will drop :-) "One oft wonders what the vintners buy, one half so precious as what they sell" - the Rubayyat of Omar Khayam What is the purpose of powers, if not the exercise of their authority? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 5 13:16:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA15552 for current-outgoing; Thu, 5 Sep 1996 13:16:42 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA15544 for ; Thu, 5 Sep 1996 13:16:31 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA09771; Thu, 5 Sep 1996 13:13:53 -0700 From: Terry Lambert Message-Id: <199609052013.NAA09771@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 5 Sep 1996 13:13:52 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: <6820.841927320@time.cdrom.com> from "Jordan K. Hubbard" at Sep 5, 96 05:42:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Once again: Richard wants you to accept (or help correct) his definition > > of "problem x". Then he wants to have a definition of "acceptable > > soloutions to the class of problems of which "problem x" is a member. > > Yes, we know, can we please end this now? We are NOT approaching a > resolution and the last 5 exchanges have shown, if anything, that > we're getting farther away from one. Try addressing the issue Richard is asking you to address instead of the issue that you want to address, and we will approach a resoloution, if only an agreement to disagree. > Call it the status quo, call it inertia, call it a core team plot > against you and Richard personally, I really don't care. Multiple > people have told you the ONLY way in which change will work, you argue > that this is impractical, fine. Let's agree to disagree and move on. > You're not going to "win" this one by out-stubborning anyone. I argue that the artificial constraints implicit in the statement "the ONLY way in which change will work" assume that the change will be implemented in the existing framework. This tends to fail to accomplish anything when it is the existing framework we are trying to change. Quit holding the existing framework sacrosanct, and you and Richard will be able to find a common grounds for discussion. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 5 14:03:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA18127 for current-outgoing; Thu, 5 Sep 1996 14:03:40 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA18117 for ; Thu, 5 Sep 1996 14:03:30 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA09868; Thu, 5 Sep 1996 13:57:25 -0700 From: Terry Lambert Message-Id: <199609052057.NAA09868@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: p.richards@elsevier.co.uk (Paul Richards) Date: Thu, 5 Sep 1996 13:57:25 -0700 (MST) Cc: rkw@dataplex.net, p.richards@elsevier.co.uk, current@FreeBSD.org In-Reply-To: <573f0xx9uo.fsf@elsevier.co.uk> from "Paul Richards" at Sep 5, 96 04:25:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Umm, well can we start this thread again on a more technical basis. > > A good place to start would be to list the current shortcomings that > people have with the current build system, work out a new design that > solves them and finally come up with a solution that can be > incrementally implemented so as not to make the system unusable at any > stage. Some current shortcomings of the existing system: 1) The "code vetting" model it does not scale adequately. This is a barrier to progress. 2) The requirement that systems be incrementally implemented forces the use of evolutionary rather than revolutionary approaches. This is a barrier to progress. 3) There is an inherent sociological and territorial limit to the concept of "management by core team". The principle behind this limit is inherent to all human endeavor. Linux is currentlly reaching their own limit in this regard; it just happens to be larger because the social construct "monarchy" has a higher sociological scalability index than the socialogical construct "feudal state" (aka "core team"). Expending of energy to fight this limit detracts from applying the same energy to increase forward motion. This is a barrier to progress. Richard wants to implement a revolutionary, not evolutionary, soloution to the problem domain "the build process". He is meeting with barrier #2, which is the same barrier I met with when I wanted to implement a revolutionary soloution to the problem domain "advanced file system design". There are similar examples for other problem domains, involving other participants, some of them core team members fighting their own #2 barriers. This ignores examples of #1 and #3 barrier conflict. This is intentional editing; examples are readily available. There are also more complex barries than the tree shown; however, if these three can not be recognized, then it is unlikely that the more abstract organizational barriers could be recognized either, so it is not fruitful to pursue them at this time. > Each stage can then be prototyped and incorporated without requiring > the all singing-all dancing implementation to be prototyped from > scratch and all in one go. People may get a better idea of the purpose > of the changes if they're done in stages, phased development is > generally the best way I find to move people towards a goal that they > don't appreciate from the outset. The old saw: how do you sanely implement revoloution? The US has a complete governmental overthrow every 4-8 years, and does so without blood running in the streets. All we are discussing here is a change in the rules of order -- we don't even want an overthrow. Yes, it's possible to take the OpenBSD approach -- hold our own "Constitutional Convention" and start down the same path which led FreeBSD to where it is today -- core-bound, as progress, as well as chaos, is turned back at the bulwarks. This has hardly been proven to be effective (yet -- OpenBSD may surprise us, even if the general model computes an answer that says it probably won't). Where are the API's one calls from within the system to change the system? Is a "Constitutional Convention" the only possible answer to the question of "how do we achieve large scale progress?" or the question of "how do we change the system?"? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 5 15:29:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA25321 for current-outgoing; Thu, 5 Sep 1996 15:29:34 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA25316 for ; Thu, 5 Sep 1996 15:29:32 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id PAA13781; Thu, 5 Sep 1996 15:28:45 -0700 (PDT) To: Terry Lambert cc: current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Thu, 05 Sep 1996 13:13:52 PDT." <199609052013.NAA09771@phaeton.artisoft.com> Date: Thu, 05 Sep 1996 15:28:45 -0700 Message-ID: <13779.841962525@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Try addressing the issue Richard is asking you to address instead of > the issue that you want to address, and we will approach a resoloution, > if only an agreement to disagree. Then let's agree to disagree. You've already used up the debate budget. Jordan From owner-freebsd-current Thu Sep 5 15:37:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA25784 for current-outgoing; Thu, 5 Sep 1996 15:37:41 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA25775 for ; Thu, 5 Sep 1996 15:37:34 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA07391 for current@freebsd.org; Fri, 6 Sep 1996 08:33:19 +1000 Date: Fri, 6 Sep 1996 08:33:19 +1000 From: Bruce Evans Message-Id: <199609052233.IAA07391@godzilla.zeta.org.au> To: current@freebsd.org Subject: fixing accesses to volatile variable `time' Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk `time' is now declared volatile. This doesn't do much except to cause annoying warnings for -Wcast-qual when &time is cast to a pointer to a non-volatile when it is passed to utility functions like timevaladd(). The utility functions are not prepared to deal with volatile times; however, there is no problem for the cases where warnings are generated, because the code runs at splclock(). splclock() has the effect of making `time' nonvolatile. Accesses to `time' outside of regions protected by splclock() are usually bugs, and declaring time as volatile usually doesn't help. I think the correct way to handle this is to declare `time' as nonvolatile and almost never access it outside of regions protected by splclock(). Most of the invalid accesses to `time' are of the form `time.tv_sec' in file systems code. There are several small problems with this: 1. time.tv_sec is long, and accesses to longs are not guaranteed to be atomic. They happen to be atomic on i386's. 2. time.tv_sec may be 1 less than the `true' seconds value reported by microtime(). The worst case is approximately when time.tv_usec == 999999. The true time.tv_sec is then ahead of the reported time.tv_sec by 1 second for almost a whole clock tick every second. Applications can see the difference if they mix gettimeofday() calls with file system calls. utimes() uses microtime() and gives results inconsistent with most other fs calls. Possible fixes: (1) use microtime() everywhere. This is probably too expensive. (2) keep track of (time.tv_usec % 10000) at each clock tick and adjust the current time to match. Both of these changes require replacing hundreds of direct accesses to time.tv_sec. I started replacing time.tv_sec by macrotime() but gave up after about 100 accesses. There are larger problems accessing the full `time'. Most file systems sort of support timespecs and would need to access the full time for complete support. 3. Accesses to `time' aren't atomic even on i386's. 4. The problems in (2) are more obvious if the nanoseconds fields in file times are set to nonzero. I changed only all the accesses to the full `time' to used a new get_time() inline functions. ext2fs already calls such a function in the !__FreeBSD__ case. Bruce diff -c2 src/sys/sys/kernel.h~ src/sys/sys/kernel.h *** src/sys/sys/kernel.h~ Wed Sep 4 17:32:00 1996 --- src/sys/sys/kernel.h Tue Sep 3 03:05:01 1996 *************** *** 60,64 **** extern struct timeval boottime; extern struct timeval runtime; ! extern volatile struct timeval time; extern struct timezone tz; /* XXX */ --- 60,64 ---- extern struct timeval boottime; extern struct timeval runtime; ! extern struct timeval time; /* nonvolatile at ipl >= splclock() */ extern struct timezone tz; /* XXX */ *************** *** 72,75 **** --- 72,86 ---- extern int tickdelta; extern long timedelta; + + static __inline void + get_time(struct timeval *tvp) + { + int s; + + s = splclock(); + /* XXX should use microtime() iff tv_usec is used. */ + *tvp = time; + splx(s); + } /* From owner-freebsd-current Thu Sep 5 15:43:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26116 for current-outgoing; Thu, 5 Sep 1996 15:43:33 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA26096 for ; Thu, 5 Sep 1996 15:43:07 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA10158; Thu, 5 Sep 1996 15:40:22 -0700 From: Terry Lambert Message-Id: <199609052240.PAA10158@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 5 Sep 1996 15:40:22 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: <13779.841962525@time.cdrom.com> from "Jordan K. Hubbard" at Sep 5, 96 03:28:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Try addressing the issue Richard is asking you to address instead of > > the issue that you want to address, and we will approach a resoloution, > > if only an agreement to disagree. > > Then let's agree to disagree. You've already used up the debate budget. This particular issue is a kicker. It needs resoloution before the consequences of ignoring it become something unpleasent. No matter how bad this discussion may irk you, it's better than causing RichardBSD and TerryBSD and MikeBSD and... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 5 16:07:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA27161 for current-outgoing; Thu, 5 Sep 1996 16:07:16 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA27155 for ; Thu, 5 Sep 1996 16:07:14 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id QAA13979; Thu, 5 Sep 1996 16:06:21 -0700 (PDT) To: Terry Lambert cc: current@FreeBSD.org Subject: Re: Latest Current build failure In-reply-to: Your message of "Thu, 05 Sep 1996 15:40:22 PDT." <199609052240.PAA10158@phaeton.artisoft.com> Date: Thu, 05 Sep 1996 16:06:21 -0700 Message-ID: <13977.841964781@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > No matter how bad this discussion may irk you, it's better than > causing RichardBSD and TerryBSD and MikeBSD and... I don't see as there's anything I could do to avert such an outcome, assuming the principles were intent on branching off to that degree, and everything I could say in stating FreeBSD's own position has already been said so there's not much more I can say to dissuade them either. I've offered all that's in my "power" to offer, and if you're all waiting for better terms from me before making your decision to split, then all I can say is split now and good luck. You want the keys to the store as a prerequisite to progress and they're just not mine to give out. Jordan P.S. Perhaps my metaphors are flawed here and there, but rather than protest that you *don't* want the keys to the store at all but merely policy/concensus/communism/whatever, please keep in mind that it's only a metaphor by which I'm simply trying to make a point, that point being that that what you want, for whatever reason, you're not going to get nor is any one person empowered to give it to you. You can keep hitting your head against this wall or you can learn to scale it. From owner-freebsd-current Thu Sep 5 17:50:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA02237 for current-outgoing; Thu, 5 Sep 1996 17:50:51 -0700 (PDT) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA02231 for ; Thu, 5 Sep 1996 17:50:46 -0700 (PDT) Received: (from uucp@localhost) by frmug.org (8.6.8/8.6.9) with UUCP id CAA09862 for current@FreeBSD.org; Fri, 6 Sep 1996 02:50:40 +0200 Received: from localhost (localhost [127.0.0.1]) by xp11.frmug.org (8.7.5/8.7.3/xp11-uucp-1.1) with ESMTP id CAA27459 for ; Fri, 6 Sep 1996 02:44:25 +0200 (MET DST) Message-Id: <199609060044.CAA27459@xp11.frmug.org> To: current@FreeBSD.org Subject: current fails to compile + patch Date: Fri, 06 Sep 1996 02:44:23 +0200 From: "Philippe Charnier" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello, For some programs (libtcl, named-xfer, dig, dnsquery, host, named, named.reload, named.restart, ndc, nslookup) I got: ===> usr.bin/dig Graph cycles through dig.1 `all' not remade because of errors. Because I have `NOMANCOMPRESS= true' in my /etc/make.conf. This is due to ${target} == ${page} in bsd.man.mk. (${target} == ${page}.gz otherwise). As I was here, I also moved `.if defined(MANFILTER)/.endif' to be consistent with the other case. Don't know if it is the way to go but it works now. Index: bsd.man.mk =================================================================== RCS file: /home2h/FreeBSD.cvsroot/src/share/mk/bsd.man.mk,v retrieving revision 1.15 diff -u -r1.15 bsd.man.mk --- bsd.man.mk 1996/08/26 10:55:32 1.15 +++ bsd.man.mk 1996/09/06 00:14:44 @@ -75,20 +75,20 @@ COPY= -c ZEXT= -.if defined(MANFILTER) .for sect in ${SECTIONS} .if defined(MAN${sect}) && !empty(MAN${sect}) CLEANFILES+= ${MAN${sect}} .for page in ${MAN${sect}} -.for target in ${page} +.for target in ${.OBJDIR}/${page} all-man: ${target} ${target}: ${page} +.if defined(MANFILTER) ${MANFILTER} < ${.ALLSRC} > ${.TARGET} +.endif .endfor .endfor .endif .endfor -.endif .else ------ ------ Philippe Charnier charnier@lirmm.fr (smtp) charnier@xp11.frmug.org (uucp) ``a PC not running FreeBSD is like a venusian with no tentacles'' ------------------------------------------------------------------------ From owner-freebsd-current Thu Sep 5 19:23:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06312 for current-outgoing; Thu, 5 Sep 1996 19:23:22 -0700 (PDT) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA06307 for ; Thu, 5 Sep 1996 19:23:19 -0700 (PDT) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.7.5/8.6.12) with ESMTP id TAA05756; Thu, 5 Sep 1996 19:22:16 -0700 (PDT) Message-Id: <199609060222.TAA05756@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: Bruce Evans cc: current@freebsd.org Subject: Re: fixing accesses to volatile variable `time' Date: Thu, 05 Sep 1996 19:22:16 -0700 From: "David E. Tweten" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk bde@zeta.org.au said: >1. time.tv_sec is long, and accesses to longs are not guaranteed to > be atomic. They happen to be atomic on i386's. To satisfy my curiosity, just who makes this "guarantee?" Obviously, access to a bit is inherently atomic, but I don't recall reading any C language specification indicating that chars, shorts, or int accesses are atomic whereas longs aren't. -- David E. Tweten | 2047-bit PGP Key fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. From owner-freebsd-current Thu Sep 5 19:34:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA07148 for current-outgoing; Thu, 5 Sep 1996 19:34:00 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA07129 for ; Thu, 5 Sep 1996 19:33:54 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id CAA25593; Fri, 6 Sep 1996 02:30:26 GMT Date: Fri, 6 Sep 1996 11:30:25 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: Paul Richards , rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure In-Reply-To: <199609052057.NAA09868@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 5 Sep 1996, Terry Lambert wrote: > The old saw: how do you sanely implement revoloution? The US has a > complete governmental overthrow every 4-8 years, and does so without > blood running in the streets. All we are discussing here is a change > in the rules of order -- we don't even want an overthrow. Does revolution mean the government must sign a contract accepting responsibility for all potential damage for an unspecified period of time? From owner-freebsd-current Thu Sep 5 23:59:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA01461 for current-outgoing; Thu, 5 Sep 1996 23:59:04 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA01452 for ; Thu, 5 Sep 1996 23:59:01 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA22321; Fri, 6 Sep 1996 16:50:49 +1000 Date: Fri, 6 Sep 1996 16:50:49 +1000 From: Bruce Evans Message-Id: <199609060650.QAA22321@godzilla.zeta.org.au> To: bde@zeta.org.au, tweten@frihet.com Subject: Re: fixing accesses to volatile variable `time' Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>1. time.tv_sec is long, and accesses to longs are not guaranteed to >> be atomic. They happen to be atomic on i386's. > >To satisfy my curiosity, just who makes this "guarantee?" Obviously, No one. Accesses to ints and shorter types are just more likely to be atomic because ints are supposed to be natural and efficient. >access to a bit is inherently atomic, but I don't recall reading any C >language specification indicating that chars, shorts, or int accesses are >atomic whereas longs aren't. The C standard only guarantees that accesses to sig_atomic_t's are atomic (except in signal handlers, only write access is guaranteed - reading of any non-local variable gives undefined behaviour!). Bruce From owner-freebsd-current Fri Sep 6 08:18:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA00373 for current-outgoing; Fri, 6 Sep 1996 08:18:04 -0700 (PDT) Received: from al.imforei.apana.org.au (root@al.imforei.apana.org.au [202.12.89.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA00363; Fri, 6 Sep 1996 08:17:50 -0700 (PDT) Received: (from pjchilds@localhost) by al.imforei.apana.org.au (8.7.5/8.7.3) id AAA27734; Sat, 7 Sep 1996 00:47:27 +0930 (CST) From: Peter Childs Message-Id: <199609061517.AAA27734@al.imforei.apana.org.au> Subject: New support for Win95/NT dialup PPP (out of the box) To: freebsd-isp@freebsd.org Date: Sat, 7 Sep 1996 00:47:27 +0930 (CST) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gday. I've uploaded the following files to ftp://ftp.freebsd.org/pub/FreeBSD/incoming/ -rwxr-xr-x 1 201 1 88254 Sep 6 08:05 ppp_plus-2.1.x-release.tar.gz -rwxr-xr-x 1 201 1 503 Sep 6 08:06 ppp_plus-2.1.x-release.txt -rwxr-xr-x 1 201 1 90092 Sep 6 08:06 ppp_plus-2.2-current.tar.gz -rwxr-xr-x 1 201 1 503 Sep 6 08:06 ppp_plus-2.2-current.txt They contain drop in replacements (source) for user level ppp (ijppp) that comes with FreeBSD (both 2.1.x's and 2.2-current) They add some extra features, such as allowing the negotation of DNS name servers, and NetBIOS name servers with Microsoft Win95 and WinNT clients running PPP. An additional feature is the ability to allow PAP authentication from the password file. We use this code, in addition with a mgetty-0.99-beta compiled with AUTO_PPP to allow Win95 clients out-of-the-box dialup PPP capabilities. All they need to know is their username/password, and the phone number. No IP's, no DNS crap, no scripts, no junk. Mgetty picks up the phone, autodetects the PPP, passes of the call to ppp which enforces PAP authentication from the password file, and negotiates our DNS servers. Full source included, along with documentation (shit!) in the man page, and some sample scripts/configs that we use. And yes this has been submitted as bin/1494 and i've got the diff's against 2.2-current (as of today) if anyone wants 'em :) Regards, Peter PS. The 2.1.5 stuff has some fixes for problems in the OpenTunnel function (limit of 10 devices - groan), and a few other cosmetics. -- Peter Childs --- http://www.imforei.apana.org.au/~pjchilds Finger pjchilds@al.imforei.apana.org.au for public PGP key Drag me, drop me, treat me like an object! From owner-freebsd-current Fri Sep 6 09:44:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA11009 for current-outgoing; Fri, 6 Sep 1996 09:44:08 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA10983; Fri, 6 Sep 1996 09:44:04 -0700 (PDT) Message-Id: <199609061644.JAA10983@freefall.freebsd.org> To: current, scsi Subject: New SCSI code on the "SCSI" branch Date: Fri, 06 Sep 1996 09:44:04 -0700 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As you may have seen from the commit mail last night, I placed all of my work so far on the SCSI system onto the "SCSI" branch to allow for controlled testing and to incourage other developers to help out in the effort (hint, hint, 8-). Below I've included the relavent portion of sys/scsi/README that lists what I've done. If you have the CVS tree, you can try/work-on this code by using the following cvs command: cd /usr/src/sys cvs update -P -d -r SCSI scsi dev/aic7xxx i386/scsi i386/isa/bt5xx-445.c \ i386/isa/aha1542.c i386/isa/aic6360.c i386/isa/ncr5380.c \ i386/isa/seagate.c i386/isa/ultra14f.c i386/isa/wd7000.c \ i386/eisa/aic7770.c i386/eisa/aha1742.c i386/eisa/bt74x.c \ pci/ncr.c pci/ncrreg.h conf/files Do NOT do this: cd /usr/src/sys cvs update -P -d -r SCSI -f While the above command appears to do what you want, it adds a sticky tag of "TSCSI" on every file in the tree even if that tag is not in its corresponding RCS file. CVS will complain bitterly if you try to do ceratin opertions with your tree like this (say a cvs status or commit). Here's the README: ------Thu Sep 5 23:27:18 PDT 1996----- gibbs@FreeBSD.org 1) Made a first pass over the data structures: There is still lots of work to be done on the current set of data structures. My main changes were to remove obsolete fields, separate adapter reated information into a separate "adapter_link", and to create the scsi_queue structure. 2) Renamed flags and data structure members to lessen the differences with Open/NetBSD: There are lots of gratuitous and some not so gratuitous differences between the two camps SCSI code. I hope to bring the code bases closer together over the next month so that we can easily share controller drivers. 3) Changed how transfers are queued, started, and completed: The original scsi system has had a long standing problem with how queued transactions are handled. The root of the problem comes from the policy of deferring the reservation of controller resources until way down in the controller scsi_cmd routine where we may not have a process context and thus cannot always sleep. With these patches, the scsi system relies almost entirely on queue management instead of sleeping to handle its resources. More specifically, I've introduced a new data structure, the scsi_queue, that relates devices that share common controller resources. A scsi_queue has "openings" as do the individual scsi_links. A scsi_link is on the scsi_queue's run queue only when it has spare openings and work to do. When running a scsi_queue, the scsi_links are handled in round-robin fashion with each link allowed to send a single transaction per round. Before a transaction is dequeued, controller resources are obtained through adapter->get_cdb and attached to the scsi_xfer structure. get_cdb and free_cdb are two entry points provided by the controller drivers that encapsulate controller resource management. They should never be called directly by the controller driver (the wd7000 driver is the only current exception to this rule). Transaction ordering is also maintained by locking the scsi_link off the run queue until the controller drivers completes queueing the command. This strategy should yield greater performance since a freed controller resource can start any scsi_link attached to that device instead of only attempting to start pending transactions on the device that just completed a transaction. The round-robin scheme also ensures resource fairness when devices with multiple openings compete for a small number of resources. The scheduling algorithm should be changed to support real-time priorities. The scsi_queue structure is an opaque type to the controller drivers to make this easier to accomplish. 4) Centralized error handling and "done" processing: The scsi_cmd entry point now returns void. The controller drivers now exclusively use scsi_done() along with a properly set scsi_xfer->error to report errors. This removes superflous code paths and duplicated code. 5) Commands are built directly in the scsi_xfer structure instead of on the stack: The original design forced each and every command structure to be copied into the scsi_xfer by the scsi_scsi_cmd routine. The scsi_xfer is now obtained up front and the command built directly into the scsi_xfer->cmd_store. The members of the scsi_xfer structure are filled in directly via an inline function, scsi_prepare_xs, instead of stuffing all of them on the stack to simply be assigned into the scsi_xfer by scsi_scsi_cmd. scsi_scsi_cmd has also been replaced by scsi_schedule_xs(). 6) Converted individual controller resource management to use the queue(3) macros. Many of the drivers performed complicated list manipulations that were simplified by using the queue macros. The generic scsi layer's queue managment is also queue(3) based. 7) Removed error detection and reporting from the xxstart routines: The goal here is to make the xxstart routines as small and efficient as possible. Error detection occurs in the strategy routine or in the sense handlers. If an error is detected that may affect queued transactions, the new driver entry point clean_queue() is called to synchronously remove any entries that would have been gradually drained by the start routines in the past. 8) Added the complete driver entry point: The complete entry point is called as the last operation on a scsi_xfer before it is freed. This is the place where device usage statistic hooks should be added. In NetBSD, they have overloaded the scsi_done routine by adding an additional argument to serve this purpose which I think is the wrong approach. Currently all disk type drivers have a complete routine using the old dk_* stat stuff. Eventually I'd like to bring in NetBSD's disk status code which is much cleaner and provides more information. 9) Removed the async driver entry point: This entry point has never been used. 10) Brough in Jason Thorpe's ch driver. I haven't added the quirk entries for the supported changers yet, but we should probably invert the meaning of our quirks (probe multiple luns by default) first. 11) Set the lun in the second byte of CDBs. This was brought up on the NetBSD lists and the lack of setting it is probably the main reason for our code probing multiple luns on so many devices. The SCSI-II spec allows for the lun to be set although it is "optional". 12) Removed the need for a static scsi_link prototype and dummy scsi_device entry in each controller driver. 13) Added tagged queueing support to the generic SCSI code and modified the aic7xxx driver to use it. We now honor the B_ORDERED buffer flag and convert sync writes to async/ordered writes if the target device does tagged queueing. 14) Added proper, timeout based, retries for the XS_BUSY case. We don't retry until either the timeout expires or the target successfully completes a command. This should also be done for the QUEUE FULL condition, but that is NYI. 15) Brought in NetBSD's scsi_message.h file and converted the generic scsi scsi layer and the aic7xxx driver to use its constants instead of home grown ones. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Fri Sep 6 10:18:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA14263 for current-outgoing; Fri, 6 Sep 1996 10:18:00 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA14245 for ; Fri, 6 Sep 1996 10:17:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA11386; Fri, 6 Sep 1996 10:11:11 -0700 From: Terry Lambert Message-Id: <199609061711.KAA11386@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: michaelh@cet.co.jp Date: Fri, 6 Sep 1996 10:11:11 -0700 (MST) Cc: terry@lambert.org, p.richards@elsevier.co.uk, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: from "Michael Hancock" at Sep 6, 96 11:30:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > The old saw: how do you sanely implement revoloution? The US has a > > complete governmental overthrow every 4-8 years, and does so without > > blood running in the streets. All we are discussing here is a change > > in the rules of order -- we don't even want an overthrow. > > Does revolution mean the government must sign a contract accepting > responsibility for all potential damage for an unspecified period of time? Yes. It means subjecting themselves to charges of malfeasance of office, and or impeachment proceedings, followed by criminal charges. The point of an oath of office is to establish this accountability. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 6 11:20:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA17829 for current-outgoing; Fri, 6 Sep 1996 11:20:57 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA17806 for ; Fri, 6 Sep 1996 11:20:50 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA26524 for ; Fri, 6 Sep 1996 20:20:46 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA13443 for freebsd-current@FreeBSD.org; Fri, 6 Sep 1996 20:20:46 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id TAA05126 for freebsd-current@FreeBSD.org; Fri, 6 Sep 1996 19:54:53 +0200 (MET DST) From: J Wunsch Message-Id: <199609061754.TAA05126@uriah.heep.sax.de> Subject: Re: fixing accesses to volatile variable `time' To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 6 Sep 1996 19:54:53 +0200 (MET DST) In-Reply-To: <199609052233.IAA07391@godzilla.zeta.org.au> from Bruce Evans at "Sep 6, 96 08:33:19 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > I changed only all the accesses to the full `time' to used a new > get_time() inline functions. ext2fs already calls such a function > in the !__FreeBSD__ case. pcvt references the `time' variable for the only purpose to avoid rescheduling the screen saver more than once per second. I would consider access of this kind being too less important to muck with the ipl. (Nothing bad happens when the clock interrupt occurs inmidst this test.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Sep 6 12:31:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA21438 for current-outgoing; Fri, 6 Sep 1996 12:31:26 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA21432 for ; Fri, 6 Sep 1996 12:31:21 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA13881; Sat, 7 Sep 1996 05:26:36 +1000 Date: Sat, 7 Sep 1996 05:26:36 +1000 From: Bruce Evans Message-Id: <199609061926.FAA13881@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: fixing accesses to volatile variable `time' Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >pcvt references the `time' variable for the only purpose to avoid >rescheduling the screen saver more than once per second. I would >consider access of this kind being too less important to muck with the >ipl. (Nothing bad happens when the clock interrupt occurs inmidst >this test.) I noticed similar cases in the networking code. These cases could use a macro sloppytime(). This would normally be defined as time.tv_sec. It usually gives the current time in seconds, but callers must be prepared for it quite often being wrong by -1 and sometimes being random. pcvt mucks with the ipl anyway. It misuses splhigh(). It should use spltty() for its own stuff and splclock() if it really cares about the time. Bruce From owner-freebsd-current Fri Sep 6 13:04:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA28140 for current-outgoing; Fri, 6 Sep 1996 13:04:19 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA28135 for ; Fri, 6 Sep 1996 13:04:15 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id NAA06744; Fri, 6 Sep 1996 13:03:47 -0700 (PDT) Received: from pdxlx008.intel.com by ichips.intel.com (8.7.4/jIII) id NAA29547; Fri, 6 Sep 1996 13:00:30 -0700 (PDT) Received: from pdxlx008.intel.com (loopback.jf.intel.com [127.0.0.1]) by pdxlx008.intel.com (8.7.5/8.7.3) with ESMTP id NAA29277; Fri, 6 Sep 1996 13:03:47 -0700 (PDT) Message-Id: <199609062003.NAA29277@pdxlx008.intel.com> To: "David E. Tweten" cc: Bruce Evans , current@freebsd.org Subject: Re: fixing accesses to volatile variable `time' In-reply-to: Your message of "Thu, 05 Sep 1996 19:22:16 PDT." <199609060222.TAA05756@ns.frihet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Sep 1996 13:03:47 -0700 From: Wayne Scott Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > bde@zeta.org.au said: > >1. time.tv_sec is long, and accesses to longs are not guaranteed to > > be atomic. They happen to be atomic on i386's. > > To satisfy my curiosity, just who makes this "guarantee?" Obviously, > access to a bit is inherently atomic, but I don't recall reading any C > language specification indicating that chars, shorts, or int accesses are > atomic whereas longs aren't. Intel guarantees that 32-bit accesses on a 32-bit boundary are atomic on all 32-bit Intel Architecture processors. (Pentium Pro manual volume 3 page 7-2) So as long as you align the time data structure correctly, there is no problem. ----------- Wayne Scott MD6 Architecture wscott@ichips.intel.com Work #: (503) 264-4165 Disclaimer: All views expressed are my own opinions, and not necessarily those of Intel Corporation. From owner-freebsd-current Fri Sep 6 13:23:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA28977 for current-outgoing; Fri, 6 Sep 1996 13:23:57 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA28971 for ; Fri, 6 Sep 1996 13:23:51 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id NAA02594 for ; Fri, 6 Sep 1996 13:20:03 -0700 (PDT) Message-ID: <32308726.2781E494@whistle.com> Date: Fri, 06 Sep 1996 13:18:46 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org Subject: ___dtoa missing...anyone else getting this? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When I try to compile a kernel checked out of a SUP'd csv tree I'm presently getting: # make cc -static -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline -Wunused -Wpointer-arith -nostdinc -I. -I../.. -I../../sys -I../../../include -DI386_CPU -DI486_CPU -DI586_CPU -DI686_CPU -DMSDOSFS -DNQNFS -DNFS -DFFS -DNETATALK -DINET -DDIAGNOSTIC -DCOMPAT_43 -DKERNEL -DMAXUSERS=10 genassym.o -o genassym vfprintf.o: Undefined symbol `___dtoa' referenced from text segment *** Error code 1 Stop. # this is with a newly compiled config and a system that has just done a "make world" successfully.. anyone have a clue? julian From owner-freebsd-current Fri Sep 6 14:15:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA01320 for current-outgoing; Fri, 6 Sep 1996 14:15:11 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA01315 for ; Fri, 6 Sep 1996 14:15:09 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id OAA22360 for ; Fri, 6 Sep 1996 14:15:06 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id OAA02934 for ; Fri, 6 Sep 1996 14:08:53 -0700 (PDT) Message-ID: <32309298.446B9B3D@whistle.com> Date: Fri, 06 Sep 1996 14:07:36 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org Subject: Re: ___dtoa missing..[solved] References: <32308726.2781E494@whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Elischer wrote: I recompiled the appropriate .o in libc and it magically started working.. I guess the build of libc had a hickup.. > > When I try to compile a kernel checked out of a SUP'd csv tree > I'm presently getting: > # make > cc -static -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline > -Wunused -Wpointer-arith -nostdinc -I. -I../.. -I../../sys > -I../../../include -DI386_CPU -DI486_CPU -DI586_CPU -DI686_CPU -DMSDOSFS > -DNQNFS -DNFS -DFFS -DNETATALK -DINET -DDIAGNOSTIC -DCOMPAT_43 -DKERNEL > -DMAXUSERS=10 genassym.o -o genassym > vfprintf.o: Undefined symbol `___dtoa' referenced from text segment > *** Error code 1 > > Stop. > # > > this is with a newly compiled config and a system that has just done a > "make world" successfully.. > > anyone have a clue? > > julian From owner-freebsd-current Fri Sep 6 16:26:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09285 for current-outgoing; Fri, 6 Sep 1996 16:26:06 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA09254; Fri, 6 Sep 1996 16:25:48 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id BAA05399; Sat, 7 Sep 1996 01:25:19 +0200 (MET DST) Date: Sat, 07 Sep 1996 01:25:19 +0200 Message-ID: <5397.842052319.1@critter.tfs.com> From: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/dev/ccd ccd.c [...] MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" Content-Description: Blind Carbon Copy Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To: undisclosed-recipients:; ------- =_aaaaaaaaaa Content-Type: message/rfc822 Content-Description: Original Message Subject: Re: cvs commit: src/sys/dev/ccd ccd.c [...] In-reply-to: Your message of "Fri, 06 Sep 1996 16:09:23 PDT." <199609062309.QAA08353@freefall.freebsd.org> Date: Sat, 07 Sep 1996 01:25:19 +0200 Message-ID: <5397.842052319@critter.tfs.com> From: Poul-Henning Kamp Bcc: Blind Distribution List: ; In message <199609062309.QAA08353@freefall.freebsd.org>, Poul-Henning Kamp writ es: >phk 96/09/06 16:09:23 > > Modified: sys/dev/ccd ccd.c > sys/gnu/i386/isa dgb.c > [...] > Log: > Remove devconf, it never grew up to be of any use. Just to preempt any longwinded discussions: This has been discussed a couple of times, and a very gratious deadline were given to the author of this, and now, after waiting much longer than the deadline, this code is now removed. We're talking about 2500 lines of code which is about 1% of the applicable source files, and in a typical kernel this comes out to 4-8Kb saved. I belive I have not zapped anything that shouldn't go, and apologize if I did. I even belive the tree still compiles. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. ------- =_aaaaaaaaaa-- From owner-freebsd-current Fri Sep 6 19:27:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA21324 for current-outgoing; Fri, 6 Sep 1996 19:27:18 -0700 (PDT) Received: from omnisolve.com (omnisolve.com [206.43.0.16]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA21316; Fri, 6 Sep 1996 19:27:15 -0700 (PDT) Received: (from val@localhost) by omnisolve.com (8.7.5/8.7.3) id UAA05349; Fri, 6 Sep 1996 20:19:02 GMT From: Valtaire Message-Id: <199609062019.UAA05349@omnisolve.com> Subject: Re: New support for Win95/NT dialup PPP (out of the box) To: pjchilds@imforei.apana.org.au (Peter Childs) Date: Fri, 6 Sep 1996 20:19:01 +0000 () Cc: freebsd-isp@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <199609061517.AAA27734@al.imforei.apana.org.au> from Peter Childs at "Sep 7, 96 00:47:27 am" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > We use this code, in addition with a mgetty-0.99-beta compiled > with AUTO_PPP to allow Win95 clients out-of-the-box dialup PPP > capabilities. All they need to know is their username/password, > and the phone number. No IP's, no DNS crap, no scripts, no > junk. This is great news for us, 3/4 of tech support is spent dealing with people who cant seem to install the scripts. I just have one stupid question. Where is mgetty-0.99-beta? all i see in the FreeBSD directores is mgetty+sendfax. am i dense? - Joel From owner-freebsd-current Fri Sep 6 19:34:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA21931 for current-outgoing; Fri, 6 Sep 1996 19:34:19 -0700 (PDT) Received: from omnisolve.com (omnisolve.com [206.43.0.16]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA21922; Fri, 6 Sep 1996 19:34:13 -0700 (PDT) Received: (from val@localhost) by omnisolve.com (8.7.5/8.7.3) id UAA05369; Fri, 6 Sep 1996 20:26:56 GMT From: Valtaire Message-Id: <199609062026.UAA05369@omnisolve.com> Subject: Re: New support for Win95/NT dialup PPP (out of the box) To: pjchilds@imforei.apana.org.au (Peter Childs) Date: Fri, 6 Sep 1996 20:26:56 +0000 () Cc: freebsd-isp@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <199609061517.AAA27734@al.imforei.apana.org.au> from Peter Childs at "Sep 7, 96 00:47:27 am" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk eek, i found it. btw, it's in ftp://ftp.leo.org/pub/comp/networking/communication/modem/mgetty for anyone else who had the same question :) - Joel From owner-freebsd-current Fri Sep 6 22:44:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA06970 for current-outgoing; Fri, 6 Sep 1996 22:44:17 -0700 (PDT) Received: from kanto.cc.jyu.fi (root@kanto.cc.jyu.fi [130.234.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA06965; Fri, 6 Sep 1996 22:44:14 -0700 (PDT) Received: from localhost (kallio@localhost [127.0.0.1]) by kanto.cc.jyu.fi (8.7.2/8.7.2) with ESMTP id IAA27978; Sat, 7 Sep 1996 08:44:03 +0300 (EET DST) Date: Sat, 7 Sep 1996 08:44:02 +0300 (EET DST) From: Seppo Kallio To: wosch@cs.tu-berlin.de cc: hackers@freebsd.org, Seppo Kallio , current@freebsd.org Subject: About adduser (FreeBSD 2.1.5) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello There is some problems in adduser 1. I think, it is returning success status even if it fails to create new user account 2. It is sometimes leaving the user home directory owner as root I feel there is some problem in code adding the user to the group in /etc/groups, is there some limit how many users can be in the same group. (Can this be disabled in the command with some option?) Seppo Kallio kallio@jyu.fi Computing Center Fax +358-14-603611 U of Jyväskylä 62.14N 25.44E Phone +358-14-603606 PL 35, 40351 Jyväskylä, Finland http://www.jyu.fi/~kallio From owner-freebsd-current Fri Sep 6 23:31:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA08918 for current-outgoing; Fri, 6 Sep 1996 23:31:45 -0700 (PDT) Received: from kanto.cc.jyu.fi (root@kanto.cc.jyu.fi [130.234.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA08912; Fri, 6 Sep 1996 23:31:42 -0700 (PDT) Received: from localhost (kallio@localhost [127.0.0.1]) by kanto.cc.jyu.fi (8.7.2/8.7.2) with ESMTP id JAA28624; Sat, 7 Sep 1996 09:31:40 +0300 (EET DST) Date: Sat, 7 Sep 1996 09:31:39 +0300 (EET DST) From: Seppo Kallio To: hackers@freebsd.org cc: current@freebsd.org Subject: SECURITY HOLE in FreeBSD 2.1.5 ????????!!!!!!! In-Reply-To: <31D3C997.CA9F25F@fa.tdktca.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think pwd_mkdb is making a temporaly file /etc/master.passwd.orig with read permissions to all. It is temporaly file, but when we have 4000 accounts the file exists for a while. I found this file in /etc directory after user adding procedures started to complain about the existence of this file. Second alternative is bug in our scripts, but I have not found that file name in them (I have not the author of our scripts). ----------- Plus this hole, we have had these problems: We cannot add users to the system when someone is using passwd command. It is really big problem in a node having 4000 accounts when we try to add 1000 account now when new students come in start of September. Passwd command should not lock the passwd files for the entire time after user type passwd to the time he/she succeeds to type his/hers new passwd! The adduser should manage the locking situation better. Seppo Kallio kallio@jyu.fi Computing Center Fax +358-14-603611 U of Jyväskylä 62.14N 25.44E Phone +358-14-603606 PL 35, 40351 Jyväskylä, Finland http://www.jyu.fi/~kallio From owner-freebsd-current Sat Sep 7 01:24:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA15638 for current-outgoing; Sat, 7 Sep 1996 01:24:33 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA15611; Sat, 7 Sep 1996 01:24:22 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA00356; Sat, 7 Sep 1996 10:24:19 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA26522; Sat, 7 Sep 1996 10:23:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA08791; Sat, 7 Sep 1996 10:11:45 +0200 (MET DST) From: J Wunsch Message-Id: <199609070811.KAA08791@uriah.heep.sax.de> Subject: Re: New support for Win95/NT dialup PPP (out of the box) To: val@omnisolve.com (Valtaire) Date: Sat, 7 Sep 1996 10:11:45 +0200 (MET DST) Cc: pjchilds@imforei.apana.org.au, freebsd-isp@freebsd.org, freebsd-current@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199609062026.UAA05369@omnisolve.com> from Valtaire at "Sep 6, 96 08:26:56 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Valtaire wrote: > eek, i found it. > > btw, it's in ftp://ftp.leo.org/pub/comp/networking/communication/modem/mgetty > for anyone else who had the same question :) For those like me with lacking brains, ftp.leo.org does also support ``site index'' queries. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 7 14:30:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA12283 for current-outgoing; Sat, 7 Sep 1996 14:30:06 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA12237; Sat, 7 Sep 1996 14:30:00 -0700 (PDT) Received: (from peter@localhost) by spinner.DIALix.COM (8.7.5/8.7.3) id FAA06968; Sun, 8 Sep 1996 05:29:55 +0800 (WST) Date: Sun, 8 Sep 1996 05:29:55 +0800 (WST) From: Peter Wemm Message-Id: <199609072129.FAA06968@spinner.DIALix.COM> To: current@freebsd.org Subject: ctm changes Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a "heads up!" to everybody getting ctm-cvs-cur and ctm-src-cur. These two mailing lists have been changed over to use Gary Palmer's slow mailout system. The mailout rate is 100K per 30 minutes, with an initial two chunks sent the moment the delta is created. If you "must have them asap", you can unsubscribe from the lists and subscribe instead to ctm-cvs-cur-fast and ctm-src-cur-fast, and make sure you have plenty of swap space for lotsa sendmail's running in parallel (as usual :-). The maximum delta mailout size has been increased from 3MB to 10MB, but it'll take some time before that all arrives in somebody's mailbox on the slow list. At 200K/hour, that's 1MB every 5 hours. When I mentioned this a week ago, I got quite a few positive replies and once person who said they'd change to the fast list as soon as it was done. -Peter From owner-freebsd-current Sat Sep 7 19:42:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA10600 for current-outgoing; Sat, 7 Sep 1996 19:42:38 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA10591 for ; Sat, 7 Sep 1996 19:42:35 -0700 (PDT) Received: from fiber.eng.umd.edu (fiber.eng.umd.edu [129.2.98.185]) by po1.glue.umd.edu (8.8.Beta.0/8.7.3) with ESMTP id WAA03369; Sat, 7 Sep 1996 22:42:23 -0400 (EDT) Received: from localhost (chuckr@localhost) by fiber.eng.umd.edu (8.7.5/8.7.3) with SMTP id WAA30394; Sat, 7 Sep 1996 22:42:22 -0400 (EDT) X-Authentication-Warning: fiber.eng.umd.edu: chuckr owned process doing -bs Date: Sat, 7 Sep 1996 22:42:22 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@fiber.eng.umd.edu To: Paul Traina cc: FreeBSD current Subject: Re: Long live groff... In-Reply-To: <199609080225.TAA21228@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I was looking at the new mm macros, embedded in your new groff stuff in contrib. The original authors had $Id$ strings in their tmac headers, defining the version number, which our cvs kindly overwrote. I am interested in whether you used the mm macros that came with the groff 1.10 (mm version 1.27) or the newer one (1.28) or the one that was just released yesterday, 1.29. The Makefile.sim that was in the original mm macros, and would have told me, seems to be missing also. John Fieber and I have been working with the newest mm macros, vis-a-vis the new tools (it's his project, not mine, I'm just tagging along), so I'm keenly interested in getting the version current. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Sat Sep 7 20:01:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA12739 for current-outgoing; Sat, 7 Sep 1996 20:01:36 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-166.rdcy01.pacbell.net [206.170.5.166]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA12690 for ; Sat, 7 Sep 1996 20:01:08 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id UAA00199; Sat, 7 Sep 1996 20:00:17 -0700 (PDT) Message-Id: <199609080300.UAA00199@precipice.shockwave.com> To: Chuck Robey cc: FreeBSD current Subject: Re: Long live groff... In-reply-to: Your message of "Sat, 07 Sep 1996 22:42:22 EDT." Date: Sat, 07 Sep 1996 20:00:17 -0700 From: Paul Traina Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk the ones from 1.10, it's a direct import, as prescribed by scripture. When it's time for your new 1.29 macros, please import them into contrib/tmac_mm -- then we can create src/share/tmac_mm for the Makefile and turn off the makefile in the MM subdirectory of my groff module. Paul From: Chuck Robey Subject: Re: Long live groff... I was looking at the new mm macros, embedded in your new groff stuff in contrib. The original authors had $Id$ strings in their tmac headers, defining the version number, which our cvs kindly overwrote. I am interested in whether you used the mm macros that came with the groff 1.10 (mm version 1.27) or the newer one (1.28) or the one that was just released yesterday, 1.29. The Makefile.sim that was in the original mm macros, and would have told me, seems to be missing also. John Fieber and I have been working with the newest mm macros, vis-a-vis the new tools (it's his project, not mine, I'm just tagging along), so I'm keenly interested in getting the version current. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+-----------------------------------------------