From owner-freebsd-ports Sun Nov 19 00:50:56 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19403 for ports-outgoing; Sun, 19 Nov 1995 00:50:56 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA19387 for ; Sun, 19 Nov 1995 00:50:53 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA02849 for ; Sun, 19 Nov 1995 09:50:50 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA22999 for ports@freebsd.org; Sun, 19 Nov 1995 09:50:49 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA29160 for ports@freebsd.org; Sun, 19 Nov 1995 09:11:48 +0100 From: J Wunsch Message-Id: <199511190811.JAA29160@uriah.heep.sax.de> Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with graphical threads To: ports@freebsd.org Date: Sun, 19 Nov 1995 09:11:47 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511190024.BAA01852@keltia.freenix.fr> from "Ollivier Robert" at Nov 19, 95 01:24:35 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 505 Sender: owner-ports@freebsd.org Precedence: bulk As Ollivier Robert wrote: > > It seems that Andreas Klemm said: > > Well this is _the_ coolest X11 NNTP newsreader I ever saw, here > > some infos from the WEB page: > > Just wait a few months and a friend of mine will release Newsview which the > equivalent of trn but under X11. Sigh. People should co-operate instead of competing. :( -- 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-ports Sun Nov 19 01:49:50 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA21386 for ports-outgoing; Sun, 19 Nov 1995 01:49:50 -0800 Received: from knobel.gun.de (knobel-ip.gun.de [192.109.159.141]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA21343 ; Sun, 19 Nov 1995 01:49:30 -0800 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id KAA05931; Sun, 19 Nov 1995 10:02:13 +0100 Date: Sun, 19 Nov 1995 10:02:13 +0100 (MET) From: Andreas Klemm To: Ollivier Robert cc: jkh@freebsd.org, j@uriah.heep.sax.de, ports@freebsd.org, hackers@freebsd.org Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with , graphical threads In-Reply-To: <199511190024.BAA01852@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk On Sun, 19 Nov 1995, Ollivier Robert wrote: Sounds very good what you are telling about Newsview. I'll give it a try, if it's available. > I've tried knews; it is much better than Xrn (i.e. it has threads > unlike Xrn) but I think the graphical part is poor. Nevertheless, it does it's job. And the color stuff for "hot" articles is very clever, too. Just for now it's the best newsreader I ever saw. Might be the case that Newsview is really better, ok, then I'd switch to it. But knews is available now, Newsview not. Andreas /// -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de - \/ ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<< From owner-freebsd-ports Sun Nov 19 01:50:36 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA21469 for ports-outgoing; Sun, 19 Nov 1995 01:50:36 -0800 Received: from knobel.gun.de (knobel-ip.gun.de [192.109.159.141]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA21449 ; Sun, 19 Nov 1995 01:50:17 -0800 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id JAA00486; Sun, 19 Nov 1995 09:46:38 +0100 Date: Sun, 19 Nov 1995 09:46:37 +0100 (MET) From: Andreas Klemm To: Joerg Wunsch cc: jkh@freebsd.org, ports@freebsd.org, hackers@freebsd.org Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with , graphical threads In-Reply-To: <199511181824.TAA23790@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk On Sat, 18 Nov 1995, J Wunsch wrote: > As Andreas Klemm wrote: > > > I put the source, the port and the tarballs into the incoming > > directory on ftp.freebsd.org: > > > > -rwxr-xr-x 1 ftp daemon 66 Nov 18 16:38 knews-0.9.3-port.tgz > > Hmm, this file actually consists only of the ZIP file header. :-( Ummm, sorry ! Looked really a bit short. Since it's a short one... begin 664 knews-0.9.3-port.tgz M'XL(`````````^U:_W/:N!+OK_BOV&NNF_>_OY5L`DG3R^M,(7<]?5J"+4NKU>YZ5[MBE=!KWGBQ M4X!M.$X+7H"`\>"[NH&VT;)L_+3QVC0LTWH!K=VR5:+@.HTK8[MP,"=@OGN70L'_1JP>--YC6[B M(QT.9Q&-8_B)E+>_K!(VIY&^+!+=IS]K!_A/Z_4GTV%WX!Z57-9+;D9G[S]M M/.E.W?<7X[X[^?&H=F.:VJ`[F;KCV:0_=2='M46>ZHN,TCGW=98M.XVTF#=. ML>%XTFN$BU1WG5M`\3=]8?=,^0I5O* M-7$U.SWOOL=YC_O#7G]\]/U_1F/WM'_YW\8\3�?=`8DT1\3/B75JM==D>C M\XMN[WZ7*)PW+DVS0=*T[M,%*2)4*M07FM:?S)!#=]P]F?8_(@L)TS0=EQ05 M/H6?Q(*%!>CQZF?MN0U28:\H_7^Z6NYP#_`%\=]L6B+^FT;;5O%_']CH_^1B M,'"'TQW,(>*__?GXC[IW2OU;[7:[C/^F8ZKXOP]LA;,.G(D;"#D0R`.,8C[U M(4GR%$2[O,_$A@`N593X5K!Y_WONY&2\DSF>>/_-5KN]?O\=TW*$_W<WAW`=Y@&^_LN,I$'HD0ARW`#+ESX/UAVY#MII$47`BU3L&^7C MB@(,^@,72):'7D3Y(=`;CZ8YQ)1SLJ2-5#PA$1*8L)@"2T6VP9$N9@G7(9(, MXS1C5V(F),8EY92R%#.1]03X-`,>L6N(PH3R#F@:`(-CXJV6&2L2?[,<8`L0 M;2DZM02(?T42C^+,A:!C^F2E[/LMAIQ)M8JIZADJ$.WDAEX M)($Y!:U6QS0L6Z$/EKS]8X5CJ/_Z4'"U]5!J#%,W;)U';(XRGQ..[3)/6Q81 M6C>]23-4@&"^FG_\R1/@E&2>D+J4U9H9DI12$6ZB%$44\KRB\6-",)L(\DKRD)-DLM?I[P3!/A)S>Y/)1(,,+OS>YI'?.<#`JDI29 M*9J'1_T"N2ZMII)6'@IB#%;T=KW&22E9#C$F0J$P(1G+.,W0@M:=IF2YK"SE MWIHYN9+-:'YA6NDR%LRQ#-FL!G_`],ECF$(MBD1RIV.JFZ/!9@O4-BJB$/:5 M^()HS+A@EE,Q\W._]1ML_/_H'#/IG+87/G:8X6%AMPL:NNR1-E5-T4]Y'Z;7S8^]T(5'D7Y M_HM(M+M3@/\[_[<T[=M-NSQW?]IK&@MK*I7\#*-__ M,KG9503X@OJOW:K._PQ5_]T+[NL?D\&ZQY)%N,0$ZZO-@0ZDU?H#_=O6G?ZM M,O[;K9:J_^X%!]^!.&]L\$"C7L#@Y6^L`!ZP(A*Y>12!-)"R!$!$Q68!MZS( M8#B4_%X(,H'&>^(;%O'V\P3!\1("BEL#8``,VK=9S$)D_5@'+L].,V8V-ET MMD8=;8WZIRA_B/K5/2YNPAR,OTULJ_)_DGO!SC*`+_'_CM&4^;]M*O^_#]S7 MO_RN$_)UYWAD_V^9&_TW+=-9Z[]I6Y:(_W;;^)/Y_V\4;]Z\@;N(KP,M^7O=>KU^G;OAQW?=IKMLN.;^Q#WT#XTFR#O4.EO`#!>_(`! M!IWT'&/!+5P3C`PY@XB2\@"``^'H]Q,?G7545E/%[Y*`X^0RI*"Y!A4Q[(R< M![D.T)O\0QY?\&3CT5G,;$RYB039ZQJ(R72YK0C,BB-49-*L<2 MWQ?U=LIU*4LI$KRH__5$PN6NX2O+Y#&SL:Q#Z]VVW1RS/(!799G^50@D6Y\C M$5P-B7+%73' MHGIN=_J7PZ/Q?_YUYW@B_H-C6G?[/]%1Q'_;4?%_'Q`>MCRZR>,T>BS\-YT. M[LGNPO^F\\-^&/V-ST=_LW78M#=NO''WWO?E2XR."O^6K@;=D8'?)R>UVA$L M/4]>7XRF_8OA!%OJXJ`=ZBGU,3J&'M1_1=\@*-5[LYGXG>UI_]+MS4;CB^G% M]+>1.YG-2L(G/??XPWOYJUM!YD*.69:\'&`D"Q>5/Q+K+/F]<[A/\&O>\?LD MNV)2R?$7LIN&*7K/B^9GN7YN4U)04%!04%!04%!04%!04%!04%!04%!04%!0 /4%!0>$;\#R>*ZOT`4``` ` end andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de - \/ ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<< From owner-freebsd-ports Sun Nov 19 02:14:56 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA23228 for ports-outgoing; Sun, 19 Nov 1995 02:14:56 -0800 Received: from knobel.gun.de (knobel-ip.gun.de [192.109.159.141]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA23222 ; Sun, 19 Nov 1995 02:14:42 -0800 Received: (from andreas@localhost) by knobel.gun.de (8.6.12/8.6.12) id LAA13565; Sun, 19 Nov 1995 11:14:09 +0100 From: Andreas Klemm Message-Id: <199511191014.LAA13565@knobel.gun.de> Subject: STk port fails to install... To: ports@freebsd.org Date: Sun, 19 Nov 1995 11:14:09 +0100 (MET) Cc: jmacd@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 668 Sender: owner-ports@freebsd.org Precedence: bulk Just for your information.. knobel# make Checksums OK. ===> Extracting for STk-2.1.7 ===> Patching for STk-2.1.7 ===> Applying FreeBSD patches for STk-2.1.7 Ignoring previously applied (or reversed) patch. 1 out of 1 hunks ignored--saving rejects to Src/dynload.c.rej *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de - \/ ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<< From owner-freebsd-ports Sun Nov 19 06:53:10 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA05245 for ports-outgoing; Sun, 19 Nov 1995 06:53:10 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA05239 for ; Sun, 19 Nov 1995 06:53:05 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id PAA18557 ; Sun, 19 Nov 1995 15:53:03 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id PAA14494 ; Sun, 19 Nov 1995 15:53:02 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id PAA01554; Sun, 19 Nov 1995 15:42:15 +0100 (MET) From: Ollivier Robert Message-Id: <199511191442.PAA01554@keltia.freenix.fr> Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with graphical threads To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 19 Nov 1995 15:42:15 +0100 (MET) Cc: ports@FreeBSD.ORG In-Reply-To: <199511190811.JAA29160@uriah.heep.sax.de> from "J Wunsch" at Nov 19, 95 09:11:47 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1345 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ports@FreeBSD.ORG Precedence: bulk It seems that J Wunsch said: > > Sigh. People should co-operate instead of competing. :( This is not much an issue of competition. The delay is there because the author wants to go beta before releasing to the world to get a larger feedback. We're ten or so to do the alpha testing. The author wants to polish the user interface. He feels that Newsview lacks some features (like auto scoring) and that it is not yet time to put it out. I don't think he would mind some other alpha-testers so I can send the 0.23 version to anyone who ask (I'll ask him though before). There is also a mailing-list for Newsview testers. Just remember it is alpha code... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Sun Nov 19 01:34:03 MET 1995 From owner-freebsd-ports Sun Nov 19 08:51:43 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10342 for ports-outgoing; Sun, 19 Nov 1995 08:51:43 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA10327 for ; Sun, 19 Nov 1995 08:51:16 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA14446; Sun, 19 Nov 1995 17:50:55 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA28793; Sun, 19 Nov 1995 17:50:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id RAA28327; Sun, 19 Nov 1995 17:46:12 +0100 From: J Wunsch Message-Id: <199511191646.RAA28327@uriah.heep.sax.de> Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with , graphical threads To: andreas@knobel.gun.de (Andreas Klemm) Date: Sun, 19 Nov 1995 17:46:11 +0100 (MET) Cc: ports@freebsd.org In-Reply-To: from "Andreas Klemm" at Nov 19, 95 09:46:37 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 562 Sender: owner-ports@freebsd.org Precedence: bulk As Andreas Klemm wrote: > > > > -rwxr-xr-x 1 ftp daemon 66 Nov 18 16:38 knews-0.9.3-port.tgz > > > > Hmm, this file actually consists only of the ZIP file header. :-( > > Ummm, sorry ! Looked really a bit short. Since it's a short one... > > begin 664 knews-0.9.3-port.tgz Thanks, i'm going to import it (with two minor modifications, and the patch i've been posting five minutes ago). -- 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-ports Sun Nov 19 08:51:54 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10372 for ports-outgoing; Sun, 19 Nov 1995 08:51:54 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA10344 for ; Sun, 19 Nov 1995 08:51:43 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA14440; Sun, 19 Nov 1995 17:50:46 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA28785; Sun, 19 Nov 1995 17:50:45 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id RAA27637; Sun, 19 Nov 1995 17:31:59 +0100 From: J Wunsch Message-Id: <199511191631.RAA27637@uriah.heep.sax.de> Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with , graphical threads To: ports@freebsd.org Date: Sun, 19 Nov 1995 17:31:59 +0100 (MET) Cc: kjj@matematik.su.se (Karl-Johan Johnsson) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Andreas Klemm" at Nov 19, 95 10:02:13 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2358 Sender: owner-ports@freebsd.org Precedence: bulk As Andreas Klemm wrote: > > On Sun, 19 Nov 1995, Ollivier Robert wrote: > > Sounds very good what you are telling about Newsview. I'll give it > a try, if it's available. Anyway, i like knews' way to use a `standard' .newsrc file. This way, i could also intermix knews with trn when X is not available. > Just for now it's the best newsreader I ever saw. Might be the > case that Newsview is really better, ok, then I'd switch to it. > But knews is available now, Newsview not. One nit: Karl-Johan was over-eager to ``beautify'' the postings. This had the ill side-effect of botching the References: header by wrapping it onto several lines. This (and the limitation to only 8 references) is in violation of RFC1036: ..., the follow-up message should have a "References" line containing the text of the original "References" line, a blank, and the Message-ID of the original message. The patch below fixes it. --- src/pedit.c.orig Thu Oct 5 11:50:50 1995 +++ src/pedit.c Sun Nov 19 16:54:27 1995 @@ -394,38 +394,34 @@ } } -#define MAX_REFS 8 static int print_references_header(FILE *fp, ARTICLE *art) { - ARTICLE *arts[MAX_REFS + 2]; - int i = MAX_REFS + 1, col, rows; + ARTICLE **arts, *a; + int i, j; + j = 0; + a = art; do { - arts[i--] = art; - art = A_PARENT(art); - } while (i > 0 && art); - - if (art) { - while (A_PARENT(art)) - art = A_PARENT(art); - arts[i] = art; - } else { - i++; - } - - rows = 1; - col = 11 + fprintf(fp, " <%s>", arts[i++]->msgid); - while (i < MAX_REFS + 2) { - if (col + arts[i]->hash_len > 75) { - rows++; - fprintf(fp, "\n "); - col = 1; - } - col += fprintf(fp, " <%s>", arts[i++]->msgid); - } - fprintf(fp, "\n"); + a = A_PARENT(a); + j++; + } while (a); - return rows; + arts = (ARTICLE **)XtMalloc(sizeof(ARTICLE *) * j); + + a = art; + i = j; + do { + arts[--i] = a; + a = A_PARENT(a); + } while(i); + + for (i = 0; i < j; i++) + (void)fprintf(fp, " <%s>", arts[i]->msgid); + (void)fprintf(fp, "\n"); + + XtFree((char *)arts); + + return 1; } static void print_attribution(FILE *fp, char *attr, ARTICLE *art) -- 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-ports Sun Nov 19 17:02:21 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA19674 for ports-outgoing; Sun, 19 Nov 1995 17:02:21 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA19653 for ; Sun, 19 Nov 1995 17:01:59 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id AAA17770; Mon, 20 Nov 1995 00:58:47 GMT From: Michael Smith Message-Id: <199511200058.AAA17770@genesis.atrad.adelaide.edu.au> Subject: Re: Proposal 3: Non-executable file in *_DEPEND To: asami@cs.berkeley.edu (Satoshi Asami) Date: Mon, 20 Nov 1995 00:58:47 +0000 () Cc: ports@FreeBSD.ORG In-Reply-To: <199511171729.JAA00967@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 17, 95 09:29:37 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1784 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Satoshi Asami stands accused of saying: > Some people have been complaining that the dependency mechanism is not > flexible enough, i.e., {FETCH,BUILD,RUN}_DEPENDS can only take an > executable as an argument. Although this was intended to protect us > from cases when the target system has a non-standard path (e.g., > /usr/opt instead of /usr/local) by using the "which" command that will > DTRT as long as the PATH is set correctly, it was impossible to depend > on a package that doesn't contain any executables. > > Thus, I propose the following change to the *_DEPEND paradigm: > > @ For FETCH_DEPENDS, BUILD_DEPENDS and RUN_DEPENDS, if the argument > starts with a '/', the existence of the pathname will be tested > ("test -e"). Otherwise, they behave as before, and will be tested > by "which". > > @ No change to LIB_DEPENDS, DEPENDS. > > What do people think? Pardon my ignorance, but is there a PKG_DEPENDS, to list packages that the current item depends on? If so, may I suggest a possible extension to the naming convention for packages as used by this entry : package-major.minor to require an exact version of a package package to require any version of a package package>major.minor to require version major.minor or higher. And as well, a PACKAGE_USES entry to indicate other packages that aren't required, but _are_ used (for extra features, etc). > Satoshi -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-ports Mon Nov 20 04:30:48 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA03449 for ports-outgoing; Mon, 20 Nov 1995 04:30:48 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA03437 ; Mon, 20 Nov 1995 04:30:35 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id EAA00698; Mon, 20 Nov 1995 04:24:40 -0800 Date: Mon, 20 Nov 1995 04:24:40 -0800 Message-Id: <199511201224.EAA00698@silvia.HIP.Berkeley.EDU> To: andreas@knobel.gun.de CC: ports@freebsd.org, jmacd@freebsd.org, j@uriah.heep.sax.de In-reply-to: <199511191014.LAA13565@knobel.gun.de> (message from Andreas Klemm on Sun, 19 Nov 1995 11:14:09 +0100 (MET)) Subject: Re: STk port fails to install... From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@freebsd.org Precedence: bulk * knobel# make * Checksums OK. * ===> Extracting for STk-2.1.7 * ===> Patching for STk-2.1.7 * ===> Applying FreeBSD patches for STk-2.1.7 * Ignoring previously applied (or reversed) patch. * 1 out of 1 hunks ignored--saving rejects to Src/dynload.c.rej * *** Error code 1 * * Stop. * *** Error code 1 * * Stop. * *** Error code 1 * * Stop. Hmm, works here.... Joerg, does it work for you? Satoshi ------- ## hostname thud.FreeBSD.org ## make patch Checksums OK. ===> Extracting for STk-2.1.7 ===> Patching for STk-2.1.7 ## From owner-freebsd-ports Mon Nov 20 04:43:54 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA04555 for ports-outgoing; Mon, 20 Nov 1995 04:43:54 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA04548 for ; Mon, 20 Nov 1995 04:43:44 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id EAA00811; Mon, 20 Nov 1995 04:43:30 -0800 Date: Mon, 20 Nov 1995 04:43:30 -0800 Message-Id: <199511201243.EAA00811@silvia.HIP.Berkeley.EDU> To: msmith@atrad.adelaide.edu.au CC: ports@FreeBSD.ORG In-reply-to: <199511200058.AAA17770@genesis.atrad.adelaide.edu.au> (message from Michael Smith on Mon, 20 Nov 1995 00:58:47 +0000 ()) Subject: Re: Proposal 3: Non-executable file in *_DEPEND From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@FreeBSD.ORG Precedence: bulk * Pardon my ignorance, but is there a PKG_DEPENDS, to list packages that the * current item depends on? No, the package names of dependencies are not in the ports Makefiles. Only the paths (e.g., ${PORTSDIR}/lang/tcl) are there, and your lovely make will cd into that directory to do "make package-name" to retreive the package name from that Makefile. * If so, may I suggest a possible extension to the naming convention for * packages as used by this entry : * * package-major.minor to require an exact version of a package * package to require any version of a package * package>major.minor to require version major.minor or higher. This is a neat idea, but the problem is that this would require a major change in the paradigm (see above). Also, I'm not exactly sure how manageable this will be, as we have ports depended from all over the place, checking for package dependencies when a new version comes out can be pretty hard. Right now, we have a sort of collapsed scheme that makes this all very simple. It's also probably too anal, but I'm afraid to fix it would complicate the (already complex) picture too much. * And as well, a PACKAGE_USES entry to indicate other packages that aren't * required, but _are_ used (for extra features, etc). This has been suggested a few times, but I still can't understand what we can do with this. If pkg_add is not going to pull it in automatically (like RUN_DEPENDS, etc.), the most we can do is to put a printf that will print out a message -- then how is this different from just putting in an "@exec echo" line in the pkg/PLIST? Satoshi From owner-freebsd-ports Mon Nov 20 05:08:25 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA05701 for ports-outgoing; Mon, 20 Nov 1995 05:08:25 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA05696 for ; Mon, 20 Nov 1995 05:08:20 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA19646; Mon, 20 Nov 1995 13:05:28 GMT From: Michael Smith Message-Id: <199511201305.NAA19646@genesis.atrad.adelaide.edu.au> Subject: Re: Proposal 3: Non-executable file in *_DEPEND To: asami@cs.berkeley.edu (Satoshi Asami) Date: Mon, 20 Nov 1995 13:05:27 +0000 () Cc: msmith@atrad.adelaide.edu.au, ports@FreeBSD.ORG In-Reply-To: <199511201243.EAA00811@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 20, 95 04:43:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4347 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Satoshi Asami stands accused of saying: > > * Pardon my ignorance, but is there a PKG_DEPENDS, to list packages that the > * current item depends on? > > No, the package names of dependencies are not in the ports Makefiles. > Only the paths (e.g., ${PORTSDIR}/lang/tcl) are there, and your lovely > make will cd into that directory to do "make package-name" to retreive > the package name from that Makefile. Can we have one then? 8) On the basis of : for item in PKG_DEPENDS if item not installed and package available install package, continue if item not installed and port available install port, continue complain Seriously, I understand that this is hardly going to happen overnight; I'm just looking to stir up a bit of discussion as the whole prepackaged thing is the current bee in my bonnet 8) > This is a neat idea, but the problem is that this would require a > major change in the paradigm (see above). Also, I'm not exactly sure > how manageable this will be, as we have ports depended from all over > the place, checking for package dependencies when a new version comes > out can be pretty hard. The baseline idea is to come up with a scheme which is simpler. I'm not sure if this is necessarily the right way however. My thinking is prompted by the recent questions wrt. the new fvwm port - I'm fairly sure that it would have compiled fine against any recent version of xpm, but because the xpm version was bumped in the interim, some confusion ensued. > Right now, we have a sort of collapsed scheme that makes this all very > simple. It's also probably too anal, but I'm afraid to fix it would > complicate the (already complex) picture too much. Sometime when I have a keyboard I can actually find the keys on, I'll try to put some coherent thoughts together. I spent a little time recently looking at how the RedHat Linux people do things. They're a little more rigid in their pacakge definition rules, but the "rpm" tools looked fairly similar in feature set to the pkg_* tools, so I tinkered with their graphical front end with a vague idea to making it work under FreeBSD. They have some interesting ideas, but their code is pretty awful. > * And as well, a PACKAGE_USES entry to indicate other packages that aren't > * required, but _are_ used (for extra features, etc). > > This has been suggested a few times, but I still can't understand what > we can do with this. If pkg_add is not going to pull it in > automatically (like RUN_DEPENDS, etc.), the most we can do is to put a > printf that will print out a message -- then how is this different > from just putting in an "@exec echo" line in the pkg/PLIST? Because a hypothetical interactive installer will pop up a dialog and say "The package you have installed can also make use of the following packages to provide extra functionality. Check each of the additional packages that you wish to install and click OK" or "The package you are about to remove is used by the following packages. These packages may fail or produce unexpected results if this package is removed. Check each package you also wish to remove and click OK, or click Cancel to keep everything." It would also be nice if _everything_ was listed in the PLIST file, rather than the current shorthand of listing only directories which contain files specific to the package. This breaks with things like Tcl/Tk, where you may modify or add things to a directory, and then when you pgk_delete/ pkg_add to upgrade, you lose your changes. Unless things have changed recently, pkg_delete doesn't use rm -rf either, so packages with specified directories containing subdirectories don't get cleaned out. It's also necessary in order to provide a mechanism for verifying the installation of a package, and determining whether the components of a package have changed since they were installed. If anyone's really keen, they could start thinking about pkg/ICON too 8) > Satoshi -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-ports Mon Nov 20 05:53:19 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA08573 for ports-outgoing; Mon, 20 Nov 1995 05:53:19 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA08567 for ; Mon, 20 Nov 1995 05:53:13 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id FAA01006; Mon, 20 Nov 1995 05:53:02 -0800 Date: Mon, 20 Nov 1995 05:53:02 -0800 Message-Id: <199511201353.FAA01006@silvia.HIP.Berkeley.EDU> To: msmith@atrad.adelaide.edu.au CC: msmith@atrad.adelaide.edu.au, ports@FreeBSD.ORG In-reply-to: <199511201305.NAA19646@genesis.atrad.adelaide.edu.au> (message from Michael Smith on Mon, 20 Nov 1995 13:05:27 +0000 ()) Subject: Re: Proposal 3: Non-executable file in *_DEPEND From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@FreeBSD.ORG Precedence: bulk * Can we have one then? 8) On the basis of : * * for item in PKG_DEPENDS * if item not installed and package available * install package, continue * if item not installed and port available ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the hard part. There is no easy way to get this mapping, unlike port -> package. The only file that contains this, /usr/ports/INDEX, is often out of date, not only because of my laziness, but also because we can't expect the users to grab that file off the ftp site too often. * install port, continue * complain * * Seriously, I understand that this is hardly going to happen overnight; I'm * just looking to stir up a bit of discussion as the whole prepackaged thing * is the current bee in my bonnet 8) Actually, if we allow make to go into the port dir and find the package name, it is not too difficult to implement as an extension of the current scheme. All we need is an extra check in the "not installed, ok I'll go build the port" part of the dependency part to see if the package exists and use that instead. * My thinking is prompted by the recent questions wrt. the new fvwm port - * I'm fairly sure that it would have compiled fine against any recent * version of xpm, but because the xpm version was bumped in the interim, * some confusion ensued. That confusion was caused because the fvwm port had an old "requirements" script that was used to do the dependency checking manually, before the *_DEPENDS were introduced. It won't happen any more, at least in that form. * Sometime when I have a keyboard I can actually find the keys on, I'll try * to put some coherent thoughts together. I spent a little time recently * looking at how the RedHat Linux people do things. They're a little more * rigid in their pacakge definition rules, but the "rpm" tools looked * fairly similar in feature set to the pkg_* tools, so I tinkered with * their graphical front end with a vague idea to making it work under FreeBSD. That's very cool. * They have some interesting ideas, but their code is pretty awful. ;) * Because a hypothetical interactive installer will pop up a dialog and say Yeah, that will be nice.... * It would also be nice if _everything_ was listed in the PLIST file, * rather than the current shorthand of listing only directories which contain * files specific to the package. This breaks with things like Tcl/Tk, where This is already recommended, although not mandatory. I'm planning tho bring this up as "proposal 5" or something. :) Satoshi From owner-freebsd-ports Mon Nov 20 08:14:53 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA16097 for ports-outgoing; Mon, 20 Nov 1995 08:14:53 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA16073 ; Mon, 20 Nov 1995 08:14:42 -0800 Received: from ncd.com (firewall-user@welch.ncd.com [192.43.160.250]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id IAA00751 ; Mon, 20 Nov 1995 08:14:22 -0800 Received: by ncd.com; id IAA19498; Mon, 20 Nov 1995 08:15:17 -0800 Received: from z-code.z-code.com(192.82.56.21) by welch.ncd.com via smap (g3.0.1) id xma019490; Mon, 20 Nov 95 08:15:09 -0800 Received: from zolaris.z-code.com (zolaris.z-code.com [192.82.56.41]) by z-code.z-code.com (8.6.9/8.6.9) with SMTP id IAA15313; Mon, 20 Nov 1995 08:11:46 -0800 Received: by zolaris.z-code.com (5.x/SMI-SVR4) id AA23972; Mon, 20 Nov 1995 08:09:23 -0800 From: "Ulf Zimmerman" Message-Id: <9511200809.ZM23970@zolaris.z-code.com> Date: Mon, 20 Nov 1995 08:09:21 -0800 In-Reply-To: Jaye Mathisen "Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with graphical threads" (Nov 18, 2:32pm) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: Jaye Mathisen Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with graphical threads Cc: hackers@freebsd.org, ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ports@freebsd.org Precedence: bulk On Nov 18, 2:32pm, Jaye Mathisen wrote: > Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with g > > Net Search in Netscape kicks back: > > http://www.matematik.su.se/users/kjj/knews.html >-- End of excerpt from Jaye Mathisen This address is local only :( Ulf. -- Ulf Zimmermann, NCD Software, 101 Rowland Way, Suite 300, Novato, CA 94945 phone: 415-899-7941, email: ulf@z-code.ncd.com, phone-home: 510-865-0204 From owner-freebsd-ports Mon Nov 20 11:40:08 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA00609 for ports-outgoing; Mon, 20 Nov 1995 11:40:08 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA00572 for ; Mon, 20 Nov 1995 11:40:04 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id UAA11492 ; Mon, 20 Nov 1995 20:37:41 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id UAA18349 ; Mon, 20 Nov 1995 20:37:40 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id TAA02217; Mon, 20 Nov 1995 19:48:22 +0100 (MET) From: Ollivier Robert Message-Id: <199511201848.TAA02217@keltia.freenix.fr> Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with graphical threads To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Mon, 20 Nov 1995 19:48:22 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, ports@FreeBSD.ORG In-Reply-To: <199511191442.PAA01554@keltia.freenix.fr> from "Ollivier Robert" at Nov 19, 95 03:42:15 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1354 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ports@FreeBSD.ORG Precedence: bulk It seems that Ollivier Robert said: > I don't think he would mind some other alpha-testers so I can send the 0.23 > version to anyone who ask (I'll ask him though before). There is also a > mailing-list for Newsview testers. OK, people, Newsview is available to anyone who want to test it. Remember this is alpha-code though. The 0.24 will be here tonight or today. ftp.ibp.fr:/pub/unix/news/newsview (or Newsview or nv, gotta check). There is a list for Newsview : send a mail to majordomo@frmug.fr.net with "subscribe nv-users" in the body of the message. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #7: Mon Nov 6 21:08:06 MET 1995 From owner-freebsd-ports Mon Nov 20 14:07:28 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14063 for ports-outgoing; Mon, 20 Nov 1995 14:07:28 -0800 Received: from ns.noaa.gov (NS.NOAA.GOV [140.90.231.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14056 for ; Mon, 20 Nov 1995 14:07:22 -0800 Received: from nes1.nesdis.noaa.gov (NES1.NESDIS.NOAA.GOV [140.90.231.21]) by ns.noaa.gov (8.6.9/8.6.9) with SMTP id RAA02302 for ; Mon, 20 Nov 1995 17:04:54 -0500 Received: from aries.fb3.noaa.gov by nes1.nesdis.noaa.gov (5.0/SMI-SVR4) id AA14906; Mon, 20 Nov 1995 17:05:41 +0500 Received: by aries.fb3.noaa.gov (950911.SGI.8.6.12.PATCH825/940406.SGI.AUTO) id RAA02005; Mon, 20 Nov 1995 17:06:37 -0500 Date: Mon, 20 Nov 1995 17:06:37 -0500 From: root@aries.fb3.noaa.gov (Super-User) Message-Id: <199511202206.RAA02005@aries.fb3.noaa.gov> To: ports@FreeBSD.ORG Subject: gcc for freebsd? Content-Type: text/plain Mime-Version: 1.0 X-Mailer: NCSA Mosaic 2.7b1 on Silicon Graphics X-Url: http://www.freebsd.org/ports/languages.html content-length: 351 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Sorry to bother you - Gcc is conspicuous by it's absence from your "ported" lists. Is it not portable to freebsd? If it isn't, then how did you get gnu f77 working? I thought g77 relied on gcc as it's back end! Also, I noticed the text associated with bcc - "can do 16-bit code". Is freebsd a 16-bit OS? Thanks for your insights, Steve Harris From owner-freebsd-ports Mon Nov 20 15:23:27 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA22583 for ports-outgoing; Mon, 20 Nov 1995 15:23:27 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA22557 for ; Mon, 20 Nov 1995 15:23:13 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id AAA14598 ; Tue, 21 Nov 1995 00:23:08 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id AAA18960 ; Tue, 21 Nov 1995 00:23:07 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id AAA03746; Tue, 21 Nov 1995 00:18:45 +0100 (MET) From: Ollivier Robert Message-Id: <199511202318.AAA03746@keltia.freenix.fr> Subject: Re: knews-0.9.3 ported - really, an amazing X11 Newsreader with graphical threads To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Tue, 21 Nov 1995 00:18:45 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, ports@FreeBSD.org In-Reply-To: <199511201848.TAA02217@keltia.freenix.fr> from "Ollivier Robert" at Nov 20, 95 07:48:22 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1354 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ports@FreeBSD.org Precedence: bulk It seems that Ollivier Robert said: > It seems that Ollivier Robert said: [Hmmm, second time I answer to myself, its getting worse :-)] > ftp.ibp.fr:/pub/unix/news/newsview (or Newsview or nv, gotta check). It is ftp.ibp.fr:/pub/unix/news/readers/nv > There is a list for Newsview : > > send a mail to majordomo@frmug.fr.net with "subscribe nv-users" in the body > of the message. You are encouraged to subscribe... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #7: Mon Nov 6 21:08:06 MET 1995 From owner-freebsd-ports Mon Nov 20 15:58:42 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA25847 for ports-outgoing; Mon, 20 Nov 1995 15:58:42 -0800 Received: from westhill.cdrom.com (westhill.cdrom.com [192.216.223.138]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA25835 for ; Mon, 20 Nov 1995 15:58:33 -0800 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by westhill.cdrom.com (8.6.12/8.6.11) with SMTP id PAA01389 ; Mon, 20 Nov 1995 15:58:13 -0800 X-Authentication-Warning: westhill.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: root@aries.fb3.noaa.gov (Super-User) cc: ports@freebsd.org Subject: Re: gcc for freebsd? In-reply-to: Your message of "Mon, 20 Nov 1995 17:06:37 EST." <199511202206.RAA02005@aries.fb3.noaa.gov> Date: Mon, 20 Nov 1995 15:58:12 -0800 Message-ID: <1387.816911892@westhill.cdrom.com> From: Gary Palmer Sender: owner-ports@freebsd.org Precedence: bulk Super-User wrote in message ID <199511202206.RAA02005@aries.fb3.noaa.gov>: > Gcc is conspicuous by it's absence from your "ported" lists. Is it not > portable to freebsd? If it isn't, then how did you get gnu f77 working? > I thought g77 relied on gcc as it's back end! Also, I noticed the text > associated with bcc - "can do 16-bit code". Is freebsd a 16-bit OS? gcc is supplied with the base system, we don't need to have it in ports! :-) Gary C From owner-freebsd-ports Mon Nov 20 16:14:40 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA27062 for ports-outgoing; Mon, 20 Nov 1995 16:14:40 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA27054 for ; Mon, 20 Nov 1995 16:14:37 -0800 Received: from unalBSD.usc.unal.edu.co ([200.21.26.68]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id QAA04225 for ; Mon, 20 Nov 1995 16:14:25 -0800 Received: (from pgiffuni@localhost) by unalBSD.usc.unal.edu.co (8.6.11/8.6.9) id TAA05253; Mon, 20 Nov 1995 19:19:04 GMT Date: Mon, 20 Nov 1995 19:19:01 +0000 () From: Pedro Giffuni To: freeBSD-ports@freeBSD.org Subject: SPICE and ISIS ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freeBSD.org Precedence: bulk Hi, I was trying to use SPICE , a program for electric circuit analysis, and I archied out that there was a port for 386bsd, has anyone tried to port the new version (spice3f4) for freeBSD? It needs the Athena widgets, do they come with XFree86? and... Has anyone tried to run the ISIS beta (for SCO) under freeBSD? thanks, Pedro Giffuni S. "What's the use of a good quotation if you can't change it?" -- The Doctor From owner-freebsd-ports Mon Nov 20 18:00:33 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA07545 for ports-outgoing; Mon, 20 Nov 1995 18:00:33 -0800 Received: from forgery.CS.Berkeley.EDU (forgery.CS.Berkeley.EDU [128.32.33.75]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA07540 for ; Mon, 20 Nov 1995 18:00:31 -0800 Received: (from asami@localhost) by forgery.CS.Berkeley.EDU (8.6.11/8.6.9) id SAA17124; Mon, 20 Nov 1995 18:00:23 -0800 Date: Mon, 20 Nov 1995 18:00:23 -0800 Message-Id: <199511210200.SAA17124@forgery.CS.Berkeley.EDU> To: root@aries.fb3.noaa.gov CC: ports@freebsd.org In-reply-to: <199511202206.RAA02005@aries.fb3.noaa.gov> (root@aries.fb3.noaa.gov) Subject: Re: gcc for freebsd? From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@freebsd.org Precedence: bulk * Sorry to bother you - No problem - * Gcc is conspicuous by it's absence from your "ported" lists. Is it not * portable to freebsd? Actually the opposite, gcc-2.6.3 is already in the main source tree, i.e., FreeBSD's /usr/bin/cc is gcc, so there is no reason to put another one in the ports tree. :) gcc-2.7.x is not imported yet, due to stability concerns, and it will come in as soon as we think it's stable enough. * If it isn't, then how did you get gnu f77 working? * I thought g77 relied on gcc as it's back end! Also, I noticed the text * associated with bcc - "can do 16-bit code". Is freebsd a 16-bit OS? No, it's a full 32-bit OS. I believe the thing about bcc is that you can use it to generate programs that can run on 16-bit OS's (like DOpeS) if you do something clever. Satoshi From owner-freebsd-ports Mon Nov 20 18:37:04 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA11712 for ports-outgoing; Mon, 20 Nov 1995 18:37:04 -0800 Received: from bacchus.eng.umd.edu (bacchus.eng.umd.edu [129.2.94.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA11697 for ; Mon, 20 Nov 1995 18:36:53 -0800 Received: from cappuccino.eng.umd.edu (cappuccino.eng.umd.edu [129.2.98.14]) by bacchus.eng.umd.edu (8.7/8.7) with ESMTP id VAA16888; Mon, 20 Nov 1995 21:36:51 -0500 (EST) Received: (chuckr@localhost) by cappuccino.eng.umd.edu (8.7/8.6.4) id VAA17354; Mon, 20 Nov 1995 21:36:50 -0500 (EST) Date: Mon, 20 Nov 1995 21:36:50 -0500 (EST) From: Chuck Robey X-Sender: chuckr@cappuccino.eng.umd.edu To: Super-User cc: ports@freebsd.org Subject: Re: gcc for freebsd? In-Reply-To: <199511202206.RAA02005@aries.fb3.noaa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk On Mon, 20 Nov 1995, Super-User wrote: > Sorry to bother you - > > Gcc is conspicuous by it's absence from your "ported" lists. Is it not > portable to freebsd? That's because GCC 2.6.3 is the system compiler, and not part of the ports collection. You get gcc whether of not you get any ports applications. If it isn't, then how did you get gnu f77 working? > I thought g77 relied on gcc as it's back end! Also, I noticed the text > associated with bcc - "can do 16-bit code". Is freebsd a 16-bit OS? No, FreeBSD is a fully 32 bit OS. There is no dual memory map, or anything like multiple memory models from DOS. > > Thanks for your insights, > Steve Harris > ============================================================================ Chuck Robey chuckr@eng.umd.edu -- I run FreeBSD on n3lxx and Journey2 --------------------------------------------------------------------------- The Dilbert Zone is Dilbert's new WWW home! The area features never-before-seen original sketches of Dilbert, a photo tour of Scott Adams' studio, Dilbert Trivia and memorabilia, high school photos and much more!: From owner-freebsd-ports Mon Nov 20 21:22:25 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA01516 for ports-outgoing; Mon, 20 Nov 1995 21:22:25 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA01495 ; Mon, 20 Nov 1995 21:22:19 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id GAA23261; Tue, 21 Nov 1995 06:21:30 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA15340; Tue, 21 Nov 1995 06:21:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id BAA14660; Tue, 21 Nov 1995 01:36:27 +0100 From: J Wunsch Message-Id: <199511210036.BAA14660@uriah.heep.sax.de> Subject: Re: STk port fails to install... To: asami@cs.berkeley.edu (Satoshi Asami) Date: Tue, 21 Nov 1995 01:36:25 +0100 (MET) Cc: andreas@knobel.gun.de, ports@freebsd.org, jmacd@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511201224.EAA00698@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 20, 95 04:24:40 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 394 Sender: owner-ports@freebsd.org Precedence: bulk As Satoshi Asami wrote: > > Hmm, works here.... > > Joerg, does it work for you? Sorry, i don't even know what STk could be... (something with Tk, but i don't have that either -- not ignorance, but lack of time to deal with 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-ports Mon Nov 20 23:34:51 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA20948 for ports-outgoing; Mon, 20 Nov 1995 23:34:51 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA20940 ; Mon, 20 Nov 1995 23:34:45 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id XAA17197; Mon, 20 Nov 1995 23:34:15 -0800 Date: Mon, 20 Nov 1995 23:34:15 -0800 Message-Id: <199511210734.XAA17197@silvia.HIP.Berkeley.EDU> To: joerg_wunsch@uriah.heep.sax.de CC: andreas@knobel.gun.de, ports@freebsd.org, jmacd@freebsd.org In-reply-to: <199511210036.BAA14660@uriah.heep.sax.de> (message from J Wunsch on Tue, 21 Nov 1995 01:36:25 +0100 (MET)) Subject: Re: STk port fails to install... From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@freebsd.org Precedence: bulk * > Joerg, does it work for you? * * Sorry, i don't even know what STk could be... (something with Tk, but * i don't have that either -- not ignorance, but lack of time to deal * with it). No, it's the "make patch" that's failing (with "reversed patch detected! oh my gosh!"), exactly like the problem you were having. Satoshi From owner-freebsd-ports Tue Nov 21 00:53:11 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA26657 for ports-outgoing; Tue, 21 Nov 1995 00:53:11 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA26650 for ; Tue, 21 Nov 1995 00:53:03 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA01030; Tue, 21 Nov 1995 09:51:26 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA16212; Tue, 21 Nov 1995 09:51:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA16911; Tue, 21 Nov 1995 09:15:11 +0100 From: J Wunsch Message-Id: <199511210815.JAA16911@uriah.heep.sax.de> Subject: Re: gcc for freebsd? To: ports@FreeBSD.ORG Date: Tue, 21 Nov 1995 09:15:11 +0100 (MET) Cc: root@aries.fb3.noaa.gov Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511210200.SAA17124@forgery.CS.Berkeley.EDU> from "Satoshi Asami" at Nov 20, 95 06:00:23 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 921 Sender: owner-ports@FreeBSD.ORG Precedence: bulk As Satoshi Asami wrote: > > * If it isn't, then how did you get gnu f77 working? > * I thought g77 relied on gcc as it's back end! Also, I noticed the text > * associated with bcc - "can do 16-bit code". Is freebsd a 16-bit OS? > > No, it's a full 32-bit OS. I believe the thing about bcc is that you > can use it to generate programs that can run on 16-bit OS's (like > DOpeS) if you do something clever. Yup. It's not directly intented to produce DOpeS code (it produces some a.out, i believe it's been a Minix one originally), however it can be abused to create a DOS .com file with minor tweaking. Bcc itself can also be compiled to produce 6809 code, which is an 8-bit CPU. Doesn't mean FreeBSD were an 8-bit operating system either. :-) -- 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-ports Tue Nov 21 01:26:48 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA28483 for ports-outgoing; Tue, 21 Nov 1995 01:26:48 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA28467 ; Tue, 21 Nov 1995 01:26:01 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA02775; Tue, 21 Nov 1995 10:21:19 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA16306; Tue, 21 Nov 1995 10:21:18 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id KAA17468; Tue, 21 Nov 1995 10:09:58 +0100 From: J Wunsch Message-Id: <199511210909.KAA17468@uriah.heep.sax.de> Subject: Re: STk port fails to install... To: asami@cs.berkeley.edu (Satoshi Asami) Date: Tue, 21 Nov 1995 10:09:58 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, andreas@knobel.gun.de, ports@freebsd.org, jmacd@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511210734.XAA17197@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 20, 95 11:34:15 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 728 Sender: owner-ports@freebsd.org Precedence: bulk As Satoshi Asami wrote: > > * > Joerg, does it work for you? > * > * Sorry, i don't even know what STk could be... (something with Tk, but > * i don't have that either -- not ignorance, but lack of time to deal > * with it). > > No, it's the "make patch" that's failing (with "reversed patch > detected! oh my gosh!"), exactly like the problem you were having. Arrgl. Ok, so i would have to get the distfile some day, in order to test it. Yes, that sound like what happened to me with xperfmon, but it only happened on freefall (for no apparent reason). -- 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-ports Tue Nov 21 02:12:26 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA04816 for ports-outgoing; Tue, 21 Nov 1995 02:12:26 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA04809 ; Tue, 21 Nov 1995 02:12:17 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id CAA00684; Tue, 21 Nov 1995 02:03:18 -0800 Date: Tue, 21 Nov 1995 02:03:18 -0800 Message-Id: <199511211003.CAA00684@silvia.HIP.Berkeley.EDU> To: joerg_wunsch@uriah.heep.sax.de CC: joerg_wunsch@uriah.heep.sax.de, andreas@knobel.gun.de, ports@freebsd.org, jmacd@freebsd.org In-reply-to: <199511210909.KAA17468@uriah.heep.sax.de> (message from J Wunsch on Tue, 21 Nov 1995 10:09:58 +0100 (MET)) Subject: Re: STk port fails to install... From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@freebsd.org Precedence: bulk * Arrgl. Ok, so i would have to get the distfile some day, in order to * test it. Yes, that sound like what happened to me with xperfmon, but * it only happened on freefall (for no apparent reason). Yeah, I remember. I wanted you to test it on freefall. :) Satoshi From owner-freebsd-ports Tue Nov 21 02:25:41 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA05596 for ports-outgoing; Tue, 21 Nov 1995 02:25:41 -0800 Received: from wiley.muc.ditec.de (wiley.muc.ditec.de [194.120.126.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA05584 ; Tue, 21 Nov 1995 02:25:16 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de ([139.92.42.164]) by wiley.muc.ditec.de (8.6.12/8.6.9) with ESMTP id LAA01953; Tue, 21 Nov 1995 11:24:51 +0100 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id NAA01113; Mon, 20 Nov 1995 13:41:29 +0100 Message-Id: <199511201241.NAA01113@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: pst@freebsd.org, ats@freebsd.org Subject: kermit bug fix Reply-To: "Julian H. Stacey" X-mailer: EXMH version 1.6.4 10/10/95 cc: ports@freebsd.org Date: Mon, 20 Nov 1995 13:41:28 +0100 From: "Julian H. Stacey" Sender: owner-ports@freebsd.org Precedence: bulk Hi pst & ast (listed in ports/comms/kermit/Makefile) CC ports I append a new comms/kermit/patches/patch-ac Would you care to do any of: corroborate it feed it back to columbia, commit it (when ports/ unfreezes) ? (Though I have commit privs, I'd like another set of eyes on it first please :-) Thanks -------- Patch by jhs@freebsd.org for cku190.tar.gz after error in manual reported by Stuart.Arnold & corroborated by jhs. *** kermit.1.orig Tue Oct 11 16:32:59 1994 --- kermit.1 Mon Nov 20 13:23:38 1995 *************** *** 577,583 **** \\Feval(expr) evaluate arithmetic expression \\Fexecute(m a) execute macro "m" with parameters "a" \\Ffiles(f) number of files matching file spec ! \\Findex(a1,a2,a3) position of string a2 in a1, starting at pos a3 \\Flength(arg) length of the string "arg" \\Fliteral(arg) copy argument literally, no evaluation \\Flower(arg) convert to lower case --- 577,583 ---- \\Feval(expr) evaluate arithmetic expression \\Fexecute(m a) execute macro "m" with parameters "a" \\Ffiles(f) number of files matching file spec ! \\Findex(a1,a2,a3) position of string a1 in a2, starting at pos a3 \\Flength(arg) length of the string "arg" \\Fliteral(arg) copy argument literally, no evaluation \\Flower(arg) convert to lower case Julian Julian H. Stacey EMAIL: jhs@freebsd.org WEB: http://www.freebsd.org/~jhs/ From owner-freebsd-ports Tue Nov 21 06:42:15 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA24285 for ports-outgoing; Tue, 21 Nov 1995 06:42:15 -0800 Received: from mail.netvision.net.il (mail.NetVision.net.il [194.90.1.6]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA24279 ; Tue, 21 Nov 1995 06:42:11 -0800 Received: from gena@NetVision.net.il (gena@burka.NetVision.net.il [194.90.6.15]) by mail.netvision.net.il (8.6.12/8.6.10) with SMTP id QAA03238; Tue, 21 Nov 1995 16:41:21 +0200 Content-Length: 1363 Message-ID: X-Mailer: XFMail 0.3 [p0] on FreeBSD MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.0.3.p0.FreeBSD:951121164209:18716=_" Reply-To: gena@NetVision.net.il X-Face: #v>4HN>#D_"[olq9y`HqTYkLVB89Xy|3')Vs9v58JQ*u-xEJVKY`xa.}E?z0RkLI/P&;BJmi0#u=W0).-Y'J4(dw{"54NhSG|YYZG@[)(`e! >jN#L!~qI5fE-JHS+< Organization: NetVision Ltd. Date: Tue, 21 Nov 1995 16:39:08 IST From: Gennady Sorokopud To: asami@FreeBSD.org Subject: xfmail-0.3 Cc: ports@FreeBSD.org Sender: owner-ports@FreeBSD.org Precedence: bulk This message is in MIME format --_=XFMail.0.3.p0.FreeBSD:951121164209:18716=_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Hello! Xfmail-0.3 finally has been released, and i update port's Makefile to reflect the changes (they are minor). Please put this new Makefile to the ports tree. Best regards. -------- Gennady B. Sorokopud - System programmer at NetVision Israel. E-Mail: Gennady Sorokopud Homepage: http://www.netvision.net.il/~gena This message was sent at 11/21/95 16:39:08 by XF-Mail --_=XFMail.0.3.p0.FreeBSD:951121164209:18716=_ Content-Description: Makefile Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; name=Makefile; SizeOnDisk=550 # New ports collection makefile for: xfmail # Version required: 0.3 # Date created: 01 October 1995 # Whom: gena # # $Id: Makefile,v 1.3 1995/10/05 12:36:18 asami Exp $ # DISTNAME= xfmail PKGNAME= xfmail-0.3 CATEGORIES+= mail x11 MASTER_SITES= ftp://burka.netvision.net.il/pub/xfmail/ MAINTAINER= gena@NetVision.net.il LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm \ xforms\\.0\\.:${PORTSDIR}/x11/xforms USE_X11= yes WRKSRC= ${WRKDIR}/xfmail-0.3/ui pre-configure: @(cd ${WRKSRC} ; cp Makefile.FreeBSD Makefile) .include --_=XFMail.0.3.p0.FreeBSD:951121164209:18716=_-- End of MIME message From owner-freebsd-ports Tue Nov 21 14:18:20 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28218 for ports-outgoing; Tue, 21 Nov 1995 14:18:20 -0800 Received: from unalBSD.usc.unal.edu.co ([200.21.26.68]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA27906 for ; Tue, 21 Nov 1995 14:13:22 -0800 Received: (from pgiffuni@localhost) by unalBSD.usc.unal.edu.co (8.6.11/8.6.9) id RAA00631; Tue, 21 Nov 1995 17:19:02 GMT Date: Tue, 21 Nov 1995 17:19:01 +0000 () From: Pedro Giffuni To: freeBSD-ports@freeBSD.org Subject: SPICE again... Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1239222546-816974341=:598" Sender: owner-ports@freeBSD.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1239222546-816974341=:598 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I am sorry I didn`t give all the information I have about SPICE. I know two versions of SPICE: SPICE2G6 ----- The more or less "original version", in FORTRAN but translated to C with f2c and some help. It has been ported to 386bsd. SPICE3f3 ----- The last version ever supported by Berkeley, it was written completely in C, and has support for Xwindows. Patches for the original version are found by anonymous ftp to ic.berkeley.edu. The best way to find it is to archie the precise version you need: archie SPICE3F3 > spice_list & download the patches and apply them. There is a port of SPICE3F4 (3F3 patched) for Linux, but I wouldn`t recommend it because it was modified to work with Linux`s libc. good luck, Pedro. Reality is bad enough, why should I tell the truth? -- Patrick Sky --0-1239222546-816974341=:598 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=readme Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCgkJCQkJCQkJSnVseSwgMTk5Mw0KDQoJU3BpY2UzZjQNCg0KLS0tLS0t LS0tLSBOZXcgZmVhdHVyZXMgaW4gU3BpY2UzZi40DQoNCldpdGggdGhpcyBy ZWxlYXNlLCB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhIHdpbGwgbm8g bG9uZ2VyDQpiZSBwcm92aWRpbmcgdGVjaG5pY2FsIHN1cHBvcnQgZm9yIFNw aWNlMywgYW5kIG5vIHBsYW5zIGhhdmUgYmVlbiBtYWRlDQpmb3IgcHJvdmlk aW5nIHN1cHBvcnQgYW55IHRpbWUgaW4gdGhlIGZ1dHVyZS4gIFNvbWUgd29y ayBvbiBTcGljZTMgd2lsbA0KY29udGludWUgKG5vdGFibHkgdGhlIEJTSU0t MyBtb2RlbCBhbmQgcGVyaGFwcyBvdGhlciBkZXZpY2UgbW9kZWxzKS4NCg0K VGhlIGZvbGxvd2luZyBpcyBhIGxpc3Qgb2YgbmV3IGZlYXR1cmVzIGFuZCBm aXhlcyBmcm9tIHRoZSBwcmV2aW91cw0KcmVsZWFzZSBvZiBTcGljZTMsIDNm LjMgKG5vdGUgdGhhdCAzZi40IGlzIGEgImxhc3QgbWludXRlIiByZWxlYXNl IHdpdGgNCm9ubHkgYSBmZXcgbmV3IGNoYW5nZXMpOg0KCUluaXRpYWwgY29u ZGl0aW9ucyBzcGVjaWZpZWQgYWNyb3NzIHZvbHRhZ2Ugc291cmNlcyBpcyBu b3cgaGFuZGxlZA0KCSJhbHRlciIgY29tbWFuZCBhY2NlcHRzIGV4cHJlc3Np b25zLCBuZXcgc3ludGF4IGlzIGVpdGhlcjoNCgkJYWx0ZXIgZGV2IHBhcmFt ID0gZXhwcg0KCQlhbHRlciBAZGV2W3BhcmFtXSA9IGV4cHINCgkiYWx0ZXJt b2QiIGNvbW1hbmQgZm9yIGFsdGVyaW5nIG1vZGVsIHBhcmFtZXRlcnMgKHdh cyAiYWx0ZXIiKQ0KCW1pbm9yIGJ1ZyBmaXhlcw0KDQpUaGUgZm9sbG93aW5n IGlzIGEgbGlzdCBvZiBuZXcgZmVhdHVyZXMgYW5kIGZpeGVzIGZyb20gdGhl IHByZXZpb3VzDQptYWpvciByZWxlYXNlIG9mIFNwaWNlMyAoM2YuMikgYW5k IHRoZSBwcmV2aW91cyByZWxlYXNlICgzZi4zKSAobm90ZQ0KdGhhdCAzZi4z IGlzIHByaW1hcmlseSBhIGJ1Zy1maXggcmVsZWFzZSBvdmVyIDNmLjIpOg0K CUFkZGVkIG5vbi1saW5lYXIgY29udHJvbGxlZCBzb3VyY2UgZnVuY3Rpb25z ICJ1KHgpIiBhbmQgInVyYW1wKHgpIg0KCUZpeGVzIHRvIEFDIHNlbnNpdGl2 aXR5IGNhbGN1bGF0aW9uDQoJRml4ZXMgdG8gaW5pdGlhbCBjb25kaXRpb25z IGNvZGUNCglGaXhlZCBzcHVyaW91cyBlcnJvciBtZXNzYWdlcyB3aGVuIHJ1 bm5pbmcgbXVsdGlwbGUgYW5heWxzZXMgaW4NCgkJYmF0Y2ggbW9kZQ0KCUZp eGVkIHBsb3R0aW5nIChhZ2FpbikNCglGaXhlZCAiYXZhaWxhYmxlIG1lbW9y eSIgY2FsY3VsYXRpb24NCglGaXhlZCBkZWZhdWx0IHNjYWxlIHRvIGJlIGxv ZyBmb3IgYW5hbHlzaXMgZG9uZSBieSBkZWNhZGUvb2N0YXZlDQoJCShhYywg ZGlzdG8sIG5vaXNlKTsgdXNlIHBsb3Qgb3B0aW9uICJsaW5lYXIiIHRvIG92 ZXJyaWRlDQoJRml4ZWQgYXNjaWlwbG90DQoJRml4ZWQgcHJvYmxlbSBjYXVz aW5nIEJTSU0gbW9kZWxzIHRvIG5vdCBiZSBmb3VuZA0KCVJlbW92ZWQgInNw aWNlZCIgKGEgcmVtb3RlLXNwaWNlIGRhZW1vbiBmb3IgQlNEIHVuaXgpOyBh ZGRlZCBhbg0KCQlyc3BpY2UgY29tbWFuZCB3aGljaCB1c2VzICJyc2giIGlu c3RlYWQuDQoJT25saW5lIGhlbHAgaW5mbyBpcyBub3cgaWRlbnRpY2xlIHRv IHRoZSAiU3BpY2UzZiBVc2VyJ3MgTWFudWFsIg0KCUZpeGVkIG51bWVyb3Vz IGFuZCB2YXJpb3VzIHBhcnNpbmcgZXJyb3JzDQoJIlRGIiBhbmFseXNpcyBv dXRwdXQgaXMgbm93IGlkZW50aWZpZWQgYXMgIlRGIiBkYXRhLCBub3QgIkRD IiBkYXRhDQoJQ29tcGxleCBudW1iZXJzIGFuZCBSZWFsIHZlY3RvcnMgYXJl IG5vdyBwcmludGVkIGJ5IHRoZQ0KCQkic2hvdyIvInNob3dtb2QiIGNvbW1h bmRzDQoJRml4ZXMgdG8gaGVscCBNYWNJbnRvc2ggcG9ydA0KCVBvcnQgZm9y IERFQyBBbHBoYSBydW5uaW5nIE9TRi8xDQoJTWlzYy4gY2hhbmdlcyB0byBp bXByb3ZlIHBvcnRhYmlsaXR5DQoNCkFkZGl0aW9uYWwgZmVhdHVyZXMgc2lu Y2UgcmVsZWFzZSAzZS4yIGFyZToNCglBQyBhbmQgREMgU2Vuc2l0aXZpdHku DQoJTU9TMyBkaXNjb250aW51aXR5IGZpeCAoImthcHBhIikuDQoJQWRkZWQg YSBuZXcgSkZFVCBmaXR0aW5nIHBhcmFtZXRlci4NCglNaW5vciBpbml0aWFs IGNvbmRpdGlvbnMgZml4Lg0KCVJld3JpdHRlbiBvciBmaXhlZCAic2hvdyIg YW5kICJ0cmFjZSIgY29tbWFuZHMuDQoJTmV3IGludGVyYWN0aXZlIGNvbW1h bmRzICJzaG93bW9kIiBhbmQgImFsdGVyIi4NCglNaW5vciBidWctZml4ZXMg dG8gdGhlIFBvbGUtWmVybyBhbmFseXNpcy4NCglNaXNjZWxsYW5lb3VzIGJ1 ZyBmaXhlcyBpbiB0aGUgZnJvbnQgZW5kLg0KDQoNCgwtLS0tLS0tLS0tICBT eXN0ZW1zIHN1cHBvcnRlZA0KDQpTcGljZTNmLjQgaGFzIGJlZW4gY29tcGls ZWQgYW5kIGFuZCBydW4gdW5kZXIgdGhlIGZvbGxvd2luZyBvcGVyYXRpbmcg c3lzdGVtczoNCglPU0YgMSwgREVDIEFscGhhDQoJVWx0cml4IDQsIFJJU0Mg b3IgVkFYDQoJU3VuT1MgNCwgU3VuMyBvciBTdW40DQoNClRoZSBmb2xsb3dp bmcgc3lzdGVtcyBoYXZlIGJlZW4gc3VjY2Vzc2Z1bGx5IHRlc3RlZCBlaXRo ZXIgaW4gdGhlIHBhc3Qgb3INCmJ5IHNvbWVvbmUgb3V0c2lkZSBvZiBVQyBC ZXJrZWxleS4NCglNUy1ET1Mgb24gdGhlIElCTSBQQywgdXNpbmcgTWljcm9T b2Z0IEMgNS4xIG9yIGxhdGVyDQoJQUlYIFYzLCBSUy82MDAwDQoJSFAtVVgg OC4wLCA5MDAwLzcwMA0KCUR5bml4IDMuMCwgU2VxdWVudCBTeW1tZXRyeSBv ciBCYWxhbmNlIChkb2VzIF9ub3RfIHRha2UgYWR2YW50YWdlIG9mIA0KCQlw YXJhbGxlbGlzbSkNCglIUC1VWCA3LjAsIDkwMDAvMzAwDQoJSXJpeCAzLjIs IFNHSSBQZXJzb25hbCBJcmlzDQoJTmVYVCAyLjANCglBcHBsZSBNYWNJbnRv c2gsIFVzaW5nIFRoaW5rIEMNCg0KT3RoZXIgc3lzdGVtcyBtYXkgcmVxdWly ZSBhIHNtYWxsIGFtb3VudCBvZiBwb3J0aW5nIGVmZm9ydC4gIE5vdGUgdGhh dA0KdGhlICdnY2MnIEMgY29tcGlsZXIgd2FzIHVzZWQgc3VjY2Vzc2Z1bGx5 IHRvIGNvbXBpbGUgU3BpY2UzZi40Lg0KDQpEdWUgdG8gdGhlIGhlYXZ5IHVz ZSBvZiBmbG9hdGluZyBwb2ludCBtYXRoIG9wZXJhdGlvbnMsIFNwaWNlMyBv biB0aGUNClBDIHJlcXVpcmVzIGEgbWF0aCBjby1wcm9jZXNzb3IuICBBbHNv LCBvbiB0aGUgUEMsIFNWR0EgZGlzcGxheXMgYXJlDQpfbm90XyBzdXBwb3J0 ZWQuICBPbmx5IENHQSwgRUdBLCBhbmQgVkdBIGRpc3BsYXlzIGFyZSBzdXBw b3J0ZWQgKHZpYQ0KdGhlIE1pY3JvU29mdCBncmFwaGljcyBsaWJyYXJ5KSBh dCB0aGlzIHRpbWUuDQoNCkEgNjgwMjAgb3IgYmV0dGVyIHByb2Nlc3NvciBh bmQgYSBtYXRoIGNvLXByb2Nlc3NvciBpcyByZXF1aXJlZCBmb3INCnRoZSBN YWNJbnRvc2guDQoNClN5c3RlbXMgdXNpbmcgdGhlIFgxMSBXaW5kb3cgU3lz dGVtIChnZW5lcmFsbHkgYW55ICJ3b3Jrc3RhdGlvbiIgY2xhc3MNCm9mIHN5 c3RlbSkgbXVzdCBoYXZlIHRoZSBNSVQgQXRoZW5hIFdpZGdldCBTZXQgIGF2 YWlsYWJsZSAoImxpYlhhdy5hIg0KYW5kIHBvc3NpYmxlbHkgImxpYlhtdS5h IikuICBUaGVzZSBhcmUgZnJlcXVlbnRseSBub3QgZGlzdHJpYnV0ZWQgb3IN CmRpc3RyaWJ1dGVkIGFzICJ1c3VwcG9ydGVkIHNvZnR3YXJlIiBieSBjb21t ZXJjaWFsIHdvcmtzdGF0aW9uDQp2ZW5kb3JzLg0KDQoMLS0tLS0tLS0tLSBV bmxvYWRpbmcgU3BpY2UzIGZyb20gZGlzayBvciB0YXBlDQoNClRoZSBVbml4 IGRpc3RyaWJ1dGlvbiBjb21lcyBvbiAxLzIiIDktdHJhY2sgdGFwZSwgOG1t IHRhcGUsIG9yIERFQyBUSzUwIHRhcGUNCmluICJ0YXIiIGZvcm1hdC4gIFRo ZSBNUy1ET1MgZGlzdHJpYnV0aW9uIGNvbWVzIG9uIHNldmVyYWwgMy41IiBm bG9wcHkNCmRpc2tldHRlcyAoYm90aCBoaWdoIGFuZCBsb3cgZGVuc2l0eSkg aW4gdGhlIHN0YW5kYXJkIE1TLURPUyBmb3JtYXQuDQpUaGUgY29udGVudHMg b2YgYm90aCBkaXN0cmlidXRpb25zIGFyZSBpZGVudGljYWwsIGluY2x1ZGlu ZyBmaWxlbmFtZXMsDQpleGNlcHQgZm9yIHRoZSBhZGRpdGlvbmFsIGZpbGVz IG9uIHRoZSBNUy1ET1MgZGlza3MgdXNlZCBmb3IgYXV0b21hdGljDQp1bmxv YWRpbmcuDQoNClRoZSBzb3VyY2UgY29kZSBhbmQgYXNzb2NpYXRlZCBkYXRh IGZpbGVzIGZvciBzcGljZTNmLjQgcmVxdWlyZSBvdmVyIDZNQiwNCmFuZCB1 cCB0byBhbiBhZGRpdGlvbmFsIDIyTUIgbWF5IGJlIHJlcXVpcmVkIHRvIGNv bXBpbGUgdW5kZXIgVW5peCAoZm9yIGENCkRFQyBSSVNDIHdvcmtzdGF0aW9u IHdpdGggdGhlIGNvbXBpbGVyIG9wdGlvbiAnLWcnKS4gIEZvciBNUy1ET1Mg dXNpbmcNCk1pY3JvU29mdCBDIDUuMSBvciBsYXRlciwgbmVhcmx5IDhNQiAo YmV5b25kIHRoZSA2TUIgZm9yIHRoZSBzb3VyY2UpIGlzDQpyZXF1aXJlZC4N Cg0KVU5JWDogIFRoZSBVTklYIGRpc3RyaWJ1dGlvbiBvZiBTcGljZTNmLjQg Y29tZXMgaW4gInRhciIgZm9ybWF0LiAgVG8NCglleHRyYWN0IFNwaWNlM2Yu NCBmaXJzdCBjcmVhdGUgdGhlIGRpcmVjdG9yeSB0aGF0IHlvdSB3aXNoIHRv DQoJaG9sZCB0aGUgZGlzdHJpYnV0aW9uIGFuZCAiY2QiIGludG8gdGhhdCBk aXJlY3RvcnkuICBUaGVuDQoJZXhlY3V0ZSB0aGUgY29tbWFuZCAidGFyIHgi IChhZnRlciBtb3VudGluZyB0aGUgdGFwZSkuICBOb3RlDQoJdGhhdCBzb21l IHNpdGVzIG1heSByZXF1aXJlIHRoYXQgeW91IGV4cGxpY2l0bHkgaW5kaWNh dGUgdGhlDQoJdGFwZSBkcml2ZSBuYW1lIHdoZW4gdXNpbmcgdGhlICJ0YXIi IGNvbW1hbmQ7IHRoaXMgaXMgZG9uZSB3aXRoDQoJdGhlICdmJyBmbGFnLCBm b3IgZXhhbXBsZSAidGFyIHhmIC9kZXYvcm10MGgiLg0KDQpNUy1ET1M6ICBT cGljZTNmLjQgY29tZXMgb24gTVMtRE9TIGZvcm1hdCAzLjUiIGRpc2tzLiAg VG8gZXh0cmFjdCB0aGUNCglkaXN0cmlidXRpb24gb250byBhIGhhcmQgZGlz aywgY3JlYXRlIHRoZSBkaXJlY3Rvcnkgb24gdGhlIGhhcmQNCglkaXNrIHRo YXQgeW91IHdpc2ggdG8gaG9sZCB0aGUgc291cmNlIGNvZGUuICAiY2QiIGlu dG8gdGhhdA0KCWRpcmVjdG9yeSBvbiB0aGUgaGFyZCBkaXNrLiAgRm9yIGVh Y2ggb2YgdGhlIGRpc3RyaWJ1dGVkIGRpc2tzLA0KCUlOIE9SREVSLCBpbnNl cnQgdGhlIGRpc2sgaW50byB0aGUgZHJpdmUgKHdlJ2xsIGFzc3VtZSBkcml2 ZQ0KCSJCOiIgaGVyZSksIGFuZCBlbnRlciAiQjpVTkxPQUQgQjoiLiAgVGhp cyB3aWxsIHVzZSB0aGUgc2NyaXB0DQoJInVubG9hZC5iYXQiIHRvIGV4dHJh Y3QgdGhlIHNvdXJjZSBmaWxlcyBvZmYgb2YgdGhlIGRpc2sgYW5kDQoJaW50 byB0aGUgY3VycmVudCBkaXJlY3Rvcnkgb3IgYSBzdWJkaXJlY3Rvcnkgb2Yg dGhlIGN1cnJlbnQNCglkaXJlY3RvcnkuICBZb3UgbWlnaHQgc2VlIHRoZSBl cnJvciAiRmlsZSBub3QgZm91bmQgPz8/Pz8/Pz8uPz8/IiwNCgl0aGF0IGlz IG5vcm1hbC4NCg0KQ29udmVydGluZyB0aGUgTVMtRE9TIGZvcm1hdCBkaXNr cyB0byBVTklYOiAgVGhlIE1TLURPUyBmb3JtYXQgaXMgbm90DQoJZGlyZWN0 bHkgcmVhZGFibGUgYnkgVU5JWCBzeXN0ZW1zLiAgT25lIHB1YmxpY2FsbHkg YXZhaWxhYmxlDQoJdG9vbCBmb3IgZG9pbmcgdGhpcyBpcyBrbm93biBhcyAi bXRvb2xzIiAoc2VhcmNoIHBvcHVsYXINCglmdHAgc2l0ZXMpLCBidXQgdGhp cyBpcyBub3QgdGhlIG9ubHkgbWV0aG9kLiAgTm90ZTogSW4gTVMtRE9TLA0K CXRleHQgZmlsZSBsaW5lcyBlbmQgd2l0aCAiXk1eSiIsIHdoZXJlIHVuZGVy IFVOSVggbGluZXMgZW5kIG9ubHkNCgl3aXRoICJeSiIuICBBbHNvLCBleGVj dXRlIHBlcm1pc3Npb24gbmVlZHMgdG8gYmUgc2V0IG9uIGFsbA0KCWZpbGVz IGluIHRoZSAidXRpbC8iIHN1YmRpcmVjdG9yeSB3aGVuIG1vdmluZyB0byBV TklYLg0KDQpNQUM6ICBTcGljZTMgaXMgbm90IGRpc3RyaWJ1dGVkIGluIGEg Zm9ybWF0IGZvciB0aGUgQXBwbGUgTWFjSW50b3NoLiAgWW91DQoJbXVzdCBk ZXRlcm1pbmUgaG93IHRvIHRyYW5zZmVyIHRoZSBmaWxlcyB0byBhIE1hYyBm cm9tIHRoZSBtZWRpYSB0aGF0DQoJeW91IGhhdmUuDQoNCgwtLS0tLS0tLS0t IENvbXBpbGluZyBTcGljZTNmLjQgdW5kZXIgVU5JWA0KDQoJVG8gYnVpbGQg U3BpY2UzZi40IG9uIGEgVW5peCBzeXN0ZW0gZm9sbG93IHRoZSBzdGVwcyBi ZWxvdy4NCglGb3IgYWRkaXRpb25hbCBub3RlcyBvbiBpbnRlcm5hbCBjaGFu Z2VzIGFuZCBwb3J0aW5nIGlzc3VlcywNCglwbGVhc2UgaW5zcGVjdCB0aGUg c3ViZGlyZWN0b3J5ICJub3RlcyIuDQoNCglGaXJzdCB5b3UgbXVzdCBlZGl0 IHRoZSBmaWxlICJjb25mL2RlZmF1bHRzIiBhbmQgY2hhbmdlIHRoZQ0KCWxp c3RlZCBwYXJhbWV0ZXJzIHRvIHJlZmxlY3QgdGhlIHN0YW5kYXJkIG9yZ2Fu aXphdGlvbiBvZg0KCXNvZnR3YXJlIGF0IHlvdXIgc2l0ZS4gIEEgZGVzY3Jp cHRpb24gb2YgZWFjaCBwYXJhbWV0ZXIgaXMNCglpbmNsdWRlZCBpbiB0aGlz IGZpbGUuDQoNCglTZWNvbmQsIGZvciBlYWNoIHR5cGUgb2Ygc3lzdGVtIGF0 IHlvdXIgc2l0ZSwgeW91IG11c3QgcHJvdmlkZQ0KCWEgZmlsZSBpbiB0aGUg c2FtZSBzdWJkaXJlY3RvcnkgKCJjb25mLyIpIHdoaWNoIGNvbnRhaW5zDQoJ ZXhjZXB0aW9ucyB0byB0aGUgcHJldmlvdXNseSBlZGl0ZWQgImRlZmF1bHRz IiBmaWxlOyBub3RlIHRoYXQNCglldmVuIGlmIHlvdSBhcmUgc3VwcG9ydGlu ZyBvbmUgdHlwZSBvZiBzeXN0ZW0gd2l0aCBubw0KCWV4Y2VwdGlvbnMgdGhp cyBpcyBzdGlsbCBuZWNlc3NhcnkuICBTZXZlcmFsIGZpbGVzIGFyZSBzdXBw bGllZCBmb3INCgl0aGUgc3lzdGVtIHR5cGVzIHRoYXQgaGF2ZSBiZWVuIHRl c3RlZCB3aXRoIHRoaXMgZGlzdHJpYnV0aW9uLA0KCWluY2x1ZGluZyAibWlw cyIgKGZvciBERUNzdGF0aW9ucyksICJzdW40IiwgInNlcXVlbnQiLCAiaXJp eCIsDQoJImhwdXgiLCBhbmQgInJzNjAwMCIuDQoNCglOb3RlIHRoYXQgc29t ZSBvZiB0aGVzZSBwZXItc3lzdGVtIGRlZmluaXRpb24gZmlsZXMgaGF2ZQ0K CXNwZWNpYWwgZGVmaW5pdGlvbnMgd2hpY2ggYXJlIHJlcXVpcmVkIGZvciB0 aGUgZ2l2ZW4gc3lzdGVtIGFuZA0KCXdoaWNoIGRvIG5vdCBhcHBlYXIgaW4g dGhlICJkZWZhdWx0cyIgZmlsZS4NCg0KCU5vdGUgYWxzbyB0aGF0IHN1Y2Nl c3NmdWwgY29tcGlsaW5nIGRvZXMgbm90IGRlcGVuZCBvbiB0aGUNCglwYXJ0 aWN1bGFyIG5hbWVzIGdpdmVuIHRvIHRoZXNlICdleGNlcHRpb24nIG9yICdz eXN0ZW0NCglkZWZpbml0aW9uJyBmaWxlcy4gIEZvciBleGFtcGxlLCB0aGUg Im1pcHMiIGNvbmZpZ3VyYXRpb24gZmlsZQ0KCWNvdWxkIGhhdmUgYmVlbiBu YW1lZCAiZGVjc3RhdGlvbiI7IHRoaXMgbmFtZSBpcyB1c2VkIGZvcg0KCWdl bmVyYXRpbmcgdW5pcXVlIGRpcmVjdG9yeSBuYW1lcyBzdWNoIHRoYXQgZGlm ZmVyZW50IHN5c3RlbXMNCgl0byBub3QgdXNlIHRoZSBzYW1lIGFyZWEgZm9y IHRoZSBjb21waWxlIHByb2Nlc3MgKG1vcmUgZGV0YWlsDQoJYXJlIGxpc3Rl ZCBpbiB0aGUgImRlZmF1bHRzIiBmaWxlKS4NCg0KCUZpbmFsbHksIGl0IGlz IHBvc3NpYmxlIHRvIGNvbWJpbmUgYWRkaXRpb25hbCBmaWxlcw0KDQoJQWZ0 ZXIgdGhlIGRlZmF1bHRzIGZpbGUgaGFzIGJlZW4gZWRpdGVkIGFuZCBhIHN5 c3RlbS1kZXBlbmRlbnQNCglmaWxlIGNyZWF0ZWQgb3IgbW9kaWZpZWQsIHJ1 biB0aGUgY29tbWFuZCAidXRpbC9idWlsZCBzeXN0ZW0iDQoJZnJvbSB0aGUg ZGlyZWN0b3J5IGFib3ZlIHRoZSAidXRpbCIgc3ViZGlyZWN0b3J5OyBmb3Ig InN5c3RlbSINCgl5b3UgbXVzdCBzdWJzdGl0dXRlIHRoZSBuYW1lIG9mIHRo ZSBzeXN0ZW0tZGVwZW5kZW50IGZpbGUgdGhhdA0KCXlvdSBjcmVhdGVkIG9y IG1vZGlmaWVkIGluIHRoZSBwcmV2aW91cyBzdGVwLiAgU3BpY2UzIHdpbGwg dGhlbg0KCWJlIGJ1aWx0IHZpYSByZWN1cnNpdmUgIm1ha2UiIGNvbW1hbmRz IChpdCBtYXkgdGFrZSBhIHNldmVyYWwNCglzZWNvbmRzIHRvIGdldCBnb2lu ZyBvbiBzb21lIHN5c3RlbXMpLiAgVGhlIHRvdGFsIHRpbWUgY2FuIGJlDQoJ YXMgbGl0dGxlIGFzIDIwIG1pbnV0ZXMgb3IgYXMgbG9uZyBhcyBmb3VyIGhv dXJzIGRlcGVuZGluZyBvbg0KCXRoZSBzcGVlZCBhbmQgbG9hZCBvZiB5b3Vy IHN5c3RlbS4gIENvbXBpbGluZyBhY3Jvc3MgTkZTIHdpbGwNCglzbG93IGRv d24gY29tcGlsaW5nIHNpZ25pZmljYW50bHkuDQoNCglJZiB5b3UgaGF2ZSB0 cm91YmxlIHVzaW5nIHRoZSAiYnVpbGQiIHNjcmlwdCwgdHJ5ICJidWlsZCAt aGVscCINCglmb3IgaW5mb21hdGlvbiBvbiBkZWJ1Z2dpbmcgb3B0aW9ucy4g IFNvbWUgc3lzdGVtIGNvbWJpbmF0aW9ucw0KCW1heSByZXF1aXJlIGxpc3Rp bmcgbW9yZSB0aGFuIG9uZSBzeXN0ZW0gbmFtZSBvbiB0aGUgImJ1aWxkIiBs aW5lLA0KCWZvciBleGFtcGxlICJidWlsZCBocHV4IGhwMzAwIiB0byBidWls ZCBvbiBhbiBIUCA5MDAwLzMwMCBhcw0KCW9wcG9zZWQgdG8gYSBIUCA5MDAw LzcwMC4gIFdoZW4gdGhlIGJ1aWxkIHNjcmlwdCBoYXMgc3VjY2Vzc2Z1bGx5 DQoJY29tcGxldGVkLCBzZWUgdGhlIHNlY3Rpb24gYmVsb3cgb24gSW5zdGFs bGluZyBTcGljZTMuDQoMLS0tLS0tLS0tLSBBZGRpdGlvbmFsIE5vdGVzIG9u IENvbXBpbGluZyBTcGljZTNmLjQgdW5kZXIgVU5JWA0KDQoJTk9URTogU29t ZSBzeXN0ZW1zIGhhdmUgYSBwcm9ibGVtIHdpdGggZGlyZWN0b3J5IG5hbWVz IGNvbnRhaW5pbmcNCglhICItIiBpbiBlaXRoZXIgdGhlIGZ1bGwgc291cmNl IGRpcmVjdG9yeSBuYW1lIG9yIHRoZSBmdWxsIGRpcmVjdG9yeQ0KCW5hbWUg b2YgYW55IHByb2dyYW0gdXNlZCBpbiBjb21waWxpbmcuICBUaGlzIG1heSBz aG93IHVwIGFzIGFuDQoJdW5leHBlY3RlZCBvciB1bnJlYXNvbmFibGUgZXJy b3IgbWVzc2FnZS4gIEF2b2lkIGRpcmVjdG9yeSBuYW1lcw0KCXdpdGggYSAi LSIgKHRoaXMgaXMgYW4gb2xkIGJ1ZyBpbiB0aGUgIm1ha2UiIGNvbW1hbmQs IHdoaWNoIGhhcw0KCXByb3BhZ2F0ZWQgdG8gbWFueSB2ZW5kb3JzIGJlZm9y ZSBiZWluZyBmaXhlZCkuDQoNCglOT1RFOiBPbiBzb21lIHN5c3RlbXMsIHRo ZSAiYnVpbGQiIHNjcmlwdHMgc2VlbXMgc2x1Z2dpc2guICBUaGlzDQoJbWF5 IGJlIGNhdXNlZCBieSBhIGxvbmcgIiRQQVRIIiwgd2l0aCBtYW55IGVudHJp ZXMgYmVmb3JlICIvYmluIg0KCWFuZCAiL3Vzci9iaW4iOyB5b3UgbWF5IGJl IGFibGUgdG8gc3BlZWQgdXAgdGhlIHNjcmlwdCBieSB0cmltbWluZw0KCXlv dXIgIiRQQVRIIiBiZWZvcmUgcnVubmluZyB0aGUgYnVpbGQgc2NyaXB0Lg0K DQoJTk9URSAoU3VuT1MpOiAgVGhlcmUgaXMgc21hbGwgYnVnIHNvbWV3aGVy ZSBpbiBvbmUgdmVyc2lvbiBvZiB0aGUNCglTdW4tc3VwcGxpZWQgWDExIGxp YnJhcmllcy4gIFRoaXMgYnVnIHJlc3VsdHMgaW4gdGhlIGZvbGxvd2luZw0K CXJvdXRpbmVzIGJlaW5nIHVuZGVmaW5lZCBpbiB0aGUgImxpbmsiIHN0YWdl Og0KDQoJCV9nZXRfd21TaGVsbFdpZGdldENsYXNzDQoJCV9nZXRfYXBwbGlj YXRpb25TaGVsbFdpZGdldENsYXNzDQoNCglUaGlzIGlzIGFwcGFyZW50bHkg YSBwcm9ibGVtIHdpdGggdGhlIGR5bmFtaWMtbGluayB2ZXJzaW9uIG9mIHRo ZQ0KCSJYbXUiIGxpYnJhcnkuICBJZiB5b3UgaGF2ZSB0aGlzIHByb2JsZW0s IHRoZSBiZXN0IHJlcG9ydGVkIGZpeCBpcw0KCXRvIHVzZSB0aGUgZm9sbG93 aW5nIG9wdGlvbnMgb24gdGhlICJsaW5rIiBsaW5lIChlbWJlZCB0aGUgZm9s bG93aW5nDQoJaW4gdGhlIExJQlggdmFyaWFibGUgaW4gImNvbmYvc3VuNCIs IG9yIHdoZXJldmVyKToNCg0KCQktQnN0YXRpYyAtbFhtdSAtQmR5bmFtaWMN Cg0KCVRoaXMgaXMgYW50aWNpcGF0ZWQgaW4gYSBjb21tZW50IGluIHRoZSBj dXJyZW50IGNvcHkgb2YgImNvbmYvc3VuNCIuDQoNCglOT1RFOiBHTlUgbWFr ZSBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSB0cmFkaXRpb25hbCAibWFr ZSIsIGFuZA0KCWlzIG5vdCBjb21wYXRpYmxlIHdpdGggc3BpY2UzLiAgVXNp bmcgR05VIG1ha2UgbWF5IHJlc3VsdCBpbg0KCWluZmluaXRlIHJlY3Vyc2lv bi4NCg0KDQoMLS0tLS0tLS0tLSBDb21waWxpbmcgdW5kZXIgTVMtRE9TIHdp dGggTWljcm9Tb2Z0IEMgNS4xOg0KDQoJVGhlIFBDIGxhY2tzIHRoZSBwcm9n cmFtICIvYmluL3NoIiAoYW5kIG90aGVycykgd2hpY2ggdGhlIGFib3ZlDQoJ VW5peCBpbnN0YWxsYXRpb24gZGVwZW5kcyBvbi4gIEluc3RlYWQgd2UgaGF2 ZSBzdXBwbGllZCBzaW1wbGUNCgljb21waWxpbmcgc2NyaXB0cyBmb3IgdXNl IHdpdGggTWljcm9Tb2Z0IEMgNS4xLiAgVGhpcyBsZXNzDQoJZmxleGlibGUg c3lzdGVtIHJlcXVpcmVzIHRoYXQgeW91IGVkaXQgc2V2ZXJhbCBmaWxlcyBi ZWZvcmUgYnVpbGRpbmc6DQoNCgkJc3JjL2Jpbi90dW5lcGMuYyAoYnVpbHQt aW4gZmlsZSBsb2NhdGlvbnMpOyBDaGFuZ2UgdGhlIHZhbHVlcw0KCQkJb2Yg dGhlIGZvbGxvd2luZyBDIHZhcmlhYmxlcyBhcyBhcHByb3ByaWF0ZSAtLSBs ZWF2ZQ0KCQkJZG91YmxlIHF1b3RlIGFuZCBzaW5nbGUgcXVvdGUgbWFya3Mg YXMtaXMsIGFuZCB1c2UNCgkJCXR3byBiYWNrc2xhc2ggKCdcJykgY2hhcmFj dGVycyB3aGVyZSB5b3Ugd2FudCBvbmU6DQoNCgkJCVNwaWNlX0V4ZWNfRGly OiBsb2NhdGlvbiB5b3UgcGxhbiB0byBpbnN0YWxsIHNwaWNlLg0KDQoJCQlT cGljZV9MaWJfRGlyOiBsb2NhdGlvbiB5b3UgcGxhbiB0byBpbnN0YWxsIHRo ZSBzcGljZQ0KCQkJCXN0YXJ0dXAgYW5kIGRhdGEgZmlsZXMuDQoNCgkJCVNw aWNlX09wdENoYXI6IGNvbW1hbmQgbGluZSBvcHRpb24gY2hhcmFjdGVyDQoJ CQkJKGluZGljYXRlcyB3aGV0aGVyIHlvdSB3YW50IHRvIHR5cGUNCgkJCQki c3BpY2UgLXIiIG9yICJzcGljZSAvciIpLg0KDQoJCQlEZWZfRWRpdG9yOiBs b2NhdGlvbiB5b3UgcGxhbiB0byBpbnN0YWxsIHNwaWNlDQoNCgkJCUFzY2lp UmF3RmlsZTogbG9jYXRpb24geW91IHBsYW4gdG8gaW5zdGFsbCBzcGljZQ0K DQoJCQlUaGUgbGFzdCB0aHJlZSBvcHRpb25zIChub3QgbGlzdGVkIGhlcmUp IGFyZSBub3QNCgkJCXNpZ25pZmljYW50IHVuZGVyIE1TLURPUywgYnV0IHNo b3VsZCBiZSBsZWZ0IGFzIGlzDQoJCQkoYmxhbmspLg0KDQoJCXNyYy9iaW4v Y2NvbmYuYwkJRGV2aWNlcyBhbmQgYW5hbHlzZXMgZm9yICJjc3BpY2UiDQoJ CXNyYy9iaW4vYmNvbmYuYwkJRGV2aWNlcyBhbmQgYW5hbHlzZXMgZm9yICJi c3BpY2UiDQoNCgkJCVRoZSBpbml0aWFsIHNlZ21lbnQgb2YgImNjb25mLmMi IGFuZCAiYmNvbmYuYyINCgkJCWFyZSAiI2RlZmluZSIgbGluZXMgdGhhdCBk ZXRlcm1pbmUgd2hpY2ggZGV2aWNlcw0KCQkJYW5kIGFuYWx5c2VzIHNob3Vs ZCBiZSBjb21waWxlZCBpbiB0byB0aGUgc2ltdWxhdG9yLg0KCQkJRm9yIGRl dmljZXMsIHRoZSBsaW5lIGxvb2tzIGxpa2UgIiNkZWZpbmUgREVWX3h4eCIN CgkJCXdoZXJlICJ4eHgiIGlzIHRoZSBuYW1lIG9mIHNvbWUgZGV2aWNlOyAg Rm9yDQoJCQlhbmFseXNlcywgdGhlIGxpbmUgbG9va3MgbGlrZSAiI2RlZmlu ZSBBTl94eHgiLg0KCQkJTmFtZXMgYW5kIGRlc2NyaXB0aW9ucyBvZiBib3Ro IGFuYWx5c2VzIGFuZCBkZXZpY2VzDQoJCQlhcmUgYXMgbGlzdGVkIGJlbG93 ICgiRGV2aWNlcyBhbmQgQW5hbHlzZXMgc3VwcG9ydGVkDQoJCQlpbiBTcGlj ZTNmLjIiLCBhdCB0aGUgZW5kKTsgc2VlIGFsc28gdGhlIHVzZXIncyBtYW51 YWwuDQoJCQlBIHJlYXNvbmFibGUgZGVmYXVsdCBpcyBzdXBwbGllZCB3aXRo IGVhY2guDQoJCQlEbyBub3QgbW9kaWZ5IGFueXRoaW5nIGJlbG93IHRoZSBs aXN0IG9mICcjZGVmaW5lJw0KCQkJbGluZXMuDQoJCShtb3JlKQ0KDQoJCXNy Yy9pbmNsdWRlL29zX21zZG9zLmgNCgkJCUlmIHlvdSBkbyBub3Qgd2FudCB0 aGUgc3BpY2Utc3VwcGxpZWQgImhhcmRjb3B5Ig0KCQkJcm91dGluZSBmb3Ig c2VuZGluZyBwbG90cyB0byBhbiBJQk0gUGVyc29uYWwNCgkJCUdyYXBoaWNz IFByaW50ZXIgKG9yIGVxdWl2YWxlbnQpLCBjb21tZW50IG91dCB0aGUNCgkJ CSIjZGVmaW5lIFdBTlRfUENIQVJEQ09QWSIgbGluZSBuZWFyIHRoZSBib3R0 b20uDQoJCQlTb21lIHZlcnNpb25zIG9mIE1TLURPUyBjYW4ndCBub3JtYWxs eSBzZW5kIFZHQQ0KCQkJZ3JhcGhpY3MgdG8gYSBwcmludGVyLg0KDQoMCU9u Y2UgdGhlc2UgZmlsZXMgaGF2ZSBiZWVuIGVkaXRlZCwgImNkIiBpbnRvIHRo ZSB0b3AgZGlyZWN0b3J5DQoJKGFib3ZlICJ1dGlsXCIsICJzcmNcIiwgYW5k ICJjb25mXCIpIGFuZCBydW4gIm1zYzUxLmJhdCIuICBUaGUNCglzY3JpcHQg Zmlyc3Qgc2V0cyBjb21waWxlciBvcHRpb25zIGluIHRoZSBlbnZpcm9ubWVu dCBhbmQgdGhlbg0KCXByb2NlZGVzIHdpdGggdGhlIGNvbXBpbGUuICBTaW5j ZSB0aGUgZW52aXJvbm1lbnQgbWF5IG5vdCBoYXZlDQoJZW5vdWdoIHJvb20s IHlvdSBtYXkgaGF2ZSB0byBjbGVhciBzb21lIHVudXNlZCBlbnZpcm9ubWVu dA0KCXZhcmlhYmxlcyBiZWZvcmUgdGhlIGJ1aWxkLCBvdGhlcndpc2UgdGhl IGJ1aWxkIGNvdWxkIGZhaWwuDQoJTm90ZSB0aGF0IHRoZXNlIG9wdGlvbnMg YXJlIG9ubHkgdXNlZnVsIGZvciBNaWNyb1NvZnQgQyA1LjEgb3INCglsYXRl ci4NCg0KCUNvbXBpbGVyIGVycm9ycyBhcmUgd3JpdHRlbiB0byB0aGUgZmls ZSAic3JjXG1zYy5vdXQiLiAgVGhpcw0KCWluY2x1ZGVzIG1hbnkgd2Fybmlu Z3MgYmVjYXVzZSBTcGljZTMgd2FzIG9yaWdpbmFsbHkgd3JpdHRlbiBpbg0K CXByZS1BTlNJIEMgKG9yICJLJlIiIEMpIHVuZGVyIFVuaXguICBFeGNlcHQg Zm9yIHRoZXNlIChudW1lcm91cykNCgl3YXJuaW5ncywgU3BpY2UzIHNob3Vs ZCBjb21waWxlIGFuZCBydW4gd2l0aG91dCB0cm91YmxlOyBzZWUgdGhlDQoJ bmV4dCBzZWN0aW9uIG9uIGluc3RhbGxpbmcuDQoNCglDbGVhbmluZyB1cCB1 bmRlciBNUy1ET1MgKGFmdGVyIGluc3RhbGxpbmcpOg0KDQoJVG8gZGVsZXRl IHRoZSBvcmlnaW5hbCBzb3VyY2UgdHJlZSBmcm9tIHlvdXIgaGFyZCBkaXNr LCB5b3UgbWF5DQoJdXNlIHRoZSBzdXBwbGllZCBzY3JpcHQgInV0aWxcZGVs YWxsLmJhdCIuICBZb3UgbXVzdCBjb3B5DQoJdGhpcyBzY3JpcHQgb3V0c2lk ZSBvZiB0aGUgc291cmNlIHRyZWUgYmVmb3JlIHlvdSBydW4gaXQgb3IgaXQN Cgl3aWxsIHJlbW92ZSBpdHNlbGYgYmVmb3JlIGZpbmlzaGluZy4gIFJ1biB0 aGUgc2NyaXB0IGZyb20gdGhlIHRvcA0KCWRpcmVjdG9yeSBvZiB0aGUgc291 cmNlIHRyZWUgKGFib3ZlICJ1dGlsXCIpLg0KDQotLS0tLS0tLS0tIENvbXBp bGluZyBvbiB0aGUgTWFjSW50b3NoDQoNCglTaW5jZSB0aGVyZSBpcyBubyBz Y3JpcHRpbmcgbGFuZ3VhZ2Ugb24gdGhlIE1hYywgeW91IG11c3QgZG8NCglj b25zaWRlcmFibGUgd29yayB0byBidWlsZCBzcGljZTMgb24gYSBNYWMuICBU aGUgZGV0YWlscw0KCWFyZSBpbmNsdWRlZCBpbiBhIHNlcGVyYXRlIGZpbGUs ICJub3Rlcy9tYWNfcG9ydCIuDQoNCgwtLS0tLS0tLS0tIEluc3RhbGxpbmcg U3BpY2UzDQoNCglBZnRlciBzcGljZTMgYW5kIHRoZSBhc3NvY2lhdGVkIHBy b2dyYW1zIGhhdmUgYmVlbiBjcmVhdGVkLCB5b3UgbWF5DQoJdGVzdCB0aGUg cHJvZ3JhbS4gIFRoZXJlIGFyZSBhIGZldyB0ZXN0IGlucHV0cyBpbiB0aGUg ImV4YW1wbGVzIg0KCXN1YmRpcmVjdG9yeS4NCg0KCUJlY2F1c2Ugc3BpY2Uz IGlzIG5vdCBpbnN0YWxsZWQgaW4gaXQncyBmaW5hbCBkZXN0aW5hdGlvbiBh dCB0aGlzDQoJcG9pbnQsIHlvdSBzaG91bGQgc2V0IHRoZSBlbnZpcm9ubWVu dCB2YXJpYWJsZSAiU1BJQ0VfTElCX0RJUiIgdG8NCgl0aGUgImxpYiIgc3Vi ZGlyZWN0b3J5IHRvIGluZGljYXRlIHRoZSBsb2NhdGlvbiBvZiBzb21lIHN0 YXJ0dXAgZmlsZXMuDQoNCglGaW5hbGx5LCB5b3UgbWF5IGluc3RhbGwgc3Bp Y2UzIGFuZCBhc3NvY2lhdGVkIGNvbXBvbmVudHMgaW50bw0KCWEgc3RhbmRh cmQgcGxhY2UuICBVbmRlciBVbml4IHN5c3RlbXMsIHRoZSBjb21tYW5kICJ1 dGlsL2J1aWxkDQoJc3lzdGVtIGluc3RhbGwiIHdpbGwgZG8gdGhpcyBhdXRv bWF0aWNhbGx5IChhZ2FpbiBzdWJzdGl0dXRlDQoJeW91ciBzeXN0ZW0gbmFt ZSBvciB0eXBlIGZvciAic3lzdGVtIikuICBVbmRlciBNUy1ET1Mgb3IgZm9y DQoJdGhlIE1hY0ludG9zaCwgdGhlIGZpbGVzIG11c3QgYmUgY29waWVkIGV4 cGxpY2l0bHkuDQoNCglUaGUgZXhlY3V0YWJsZSBwcm9ncmFtcyBhcmUgZnJv bSB0aGUgc3ViZGlyZWN0b3JpZXMgInNyYy9iaW4iLA0KCWFzIGZvbGxvd3M6 DQoJCXNwaWNlMwkJVU5JWCBvbmx5OiB0aGUgc2ltdWxhdG9yLg0KCQlic3Bp Y2UJCU1TLURPUyBvbmx5OiBhIGJhdGNoIG1vZGUgc2ltdWxhdG9yOg0KCQkJ CSJic3BpY2UgPCBpbnB1dC5jaXIiIGdlbmVyYXRlcyB0aGUgZmlsZQ0KCQkJ CSJyYXdzcGljZS5yYXciLCB3aGljaCBpcyByZWFkIGJ5ICJudXRtZWciDQoJ CQkJKHNlZSBiZWxvdykuDQoJCWNzcGljZQkJTVMtRE9TIG9ubHk6IGEgc3Bp Y2UyIGxpa2UgaW50ZXJmYWNlIGZvcg0KCQkJCXNtYWxsIHJ1bnMgKHJ1bnMg b3V0IG9mIG1lbW9yeSBlYXNpbHkpLg0KCQkJCVVzZSAiY3NwaWNlIDwgaW5w dXQuY2lyIjsgZ2VuZXJhdGVzDQoJCQkJJ2FzY2lpcGxvdHMnIGZvciAucGxv dCBsaW5lcy4NCgkJbnV0bWVnCQlBIHN0YW5kLWFsb25lIGRhdGEgYW5hbHlz aXMgcHJvZ3JhbTsNCgkJCQlTcGljZTMgd2l0aG91dCB0aGUgc2ltdWxhdGlv biBjYXBhYmlsaXR5Lg0KCQloZWxwCQlBIHN0YW5kIGFsb25lIGhlbHAgYnJv d3Nlci4NCgkJcHJvYzJtb2QJQ29udmVydHMgcHJvY2VzcyBjaGFyYWN0ZXJp emF0aW9uIGZpbGVzDQoJCQkJdG8gU3BpY2UzIEJTSU0xIE1PUyBtb2RlbCBk ZWZpbml0aW9ucy4NCgkJc2NvbnZlcnQJQ29udmVydHMgYmV0d2VlbiBhc2Np aSBhbmQgYmluYXJ5IHNwaWNlDQoJCQkJZGF0YSBmaWxlcyAoIi5yYXciIGZp bGVzKS4NCgkJbXVsdGlkZWMJQSB1dGlsaXR5IGZvciBkZWNvbXBvc2luZyBj b3VwbGVkIGxvc3N5DQoJCQkJdHJhbnNtaXNzaW9uIGxpbmVzIGludG8gZXF1 aXZhbGVudCB1bmNvdXBsZWQNCgkJCQlsaW5lcy4gIE5vdCBhdmFpbGFibGUg b24gTVMtRE9TIChuZWVkIHRoZQ0KCQkJCSJnZXRvcHQiIGxpYnJhcnkpLg0K DQoJVGhlIGZvbGxvd2luZyBzdGFydHVwL2RhdGEgZmlsZXMgYXJlIGluc3Rh bGxlZCBmcm9tIHRoZSAibGliLyINCglzdWJkaXJlY3Rvcnk6DQoJCWhlbHBk aXIvc3BpY2UudHh0CW9uLWxpbmUgaW5mb3JtYXRpb24gZm9yIHNwaWNlMy4N CgkJaGVscGRpci9zcGljZS5pZHgJaW5kZXggZm9yIHNwaWNlLnR4dCwgZ2Vu ZXJhdGVkIHdpdGgNCgkJCQkJCXRoZSBwcm9ncmFtICJiaW4vbWFrZWlkeCIu DQoNCgkJc2NyaXB0cy9zcGluaXQJCXNwaWNlL251dG1lZyBjb21tYW5kcyBl eGVjdXRlZCBhdA0KCQkJCQkJc3RhcnR1cC4NCgkJc2NyaXB0cy9zZXRwbG90 CQlBIHNjcmlwdCBmb3IgdGhlIGNvbW1hbmQgInNldHBsb3QiLg0KDQoJCW5l d3MJCQlhIHN0YXJ0IHVwIG1lc3NhZ2Ugb2YgeW91ciBjaG9vc2luZy4NCgkJ bWZiY2FwCQkJZ3JhcGhpY3MtdGVybWluYWwgY2FwYWJpbGl0eSBkYXRhYmFz ZQ0KCQkJCQkobm90IHJlcXVpcmVkIGZvciBNUy1ET1MpLg0KDQoJKFByZXZp b3VzIHZlcnNpb25zIGhhZCBhIHNlcGVyYXRlIGhlbHAgZmlsZXMgZm9yIHNw aWNlMyBhbmQNCgludXRtZWc7ICB0aGUgY3VycmVudCBoZWxwIGZpbGUgaXMg bm93IGlkZW50aWNsZSB0byB0aGUgIlNwaWNlM2Y0DQoJVXNlcidzIE1hbnVh bCIsIHNvIHRoZXJlIGlzIG5vIGRpc3RpbmN0aW9uKS4NCg0KCUZvciB0aGUg UEMgYW5kIE1hY0ludG9zaCwgeW91IG11c3QgZ2VuZXJhdGUgdGhlICIuaWR4 IiBmaWxlcw0KCXlvdXJzZWxmIGJ5IHJ1bm5pbmcgIm1ha2VpZHggc3BpY2Uu dHh0Ii4gIFVuaXggIm1hbiIgcGFnZXMgYXJlDQoJYWxzbyBzdXBwbGllZCBm b3IgdGhlIHByb2dyYW1zIHNwaWNlLCBudXRtZWcsIGFuZCBzY29udmVydCwg Zm9yDQoJdGhlIG1mYiBkYXRhYmFzZSBmb3JtYXQgKGxvb2tzIGxpa2UgdGVy bWNhcCksIGFuZCBmb3IgdGhlIG1mYg0KCWxpYnJhcnkuICBUaGVzZSBhcmUg bm90IGluc3RhbGxlZCBhdXRvbWF0aWNhbGx5IGFzIHRoZXkgYXJlDQoJb2xk LCB1bnN1cHBvcnRlZCwgYW5kIG1heSBiZSBvdXQgb2YgZGF0ZS4NCg0KDERl dmljZXMgYW5kIEFuYWx5c2VzIHN1cHBvcnRlZCBpbiBTcGljZTNmLjQ6DQoJ Rm9yIHJlZmVyZW5jZSwgdGhlIGZvbGxvd2luZyBpcyBhIGxpc3Qgb2YgYWxs IGRldmljZXMgYW5kIHRoZWlyDQoJY29tbW9uIGFiYnJldmlhdGlvbiBpbiBT cGljZTM6DQoNCgkJYXNyYzoJYXJiaXRyYXJ5IHZvbHRhZ2UvY3VycmVudCBz b3VyY2UNCgkJYmp0OgliaXBvbGFyIGp1bmN0aW9uIHRyYW5zaXN0b3INCgkJ YnNpbTE6CWRldGFpbGVkIE1PUyBtb2RlbA0KCQlic2ltMjoJZGV0YWlsZWQg TU9TIG1vZGVsLCByZXZpc2VkIHZlcnNpb24gb2YgYnNpbTENCgkJY2FwOglj YXBhY2l0b3INCgkJY2NjczoJY3VycmVudC1jb250cm9sbGVkIGN1cnJlbnQg c291cmNlDQoJCWNjdnM6CWN1cnJlbnQtY29udHJvbGxlZCB2b2x0YWdlIHNv dXJjZQ0KCQljc3c6CWN1cnJlbnQgY29udHJvbGxlZCBzd2l0Y2gNCgkJZGlv OglkaW9kZQ0KCQlsdHJhOglsb3NzeSB0cmFuc21pc3Npb24gbGluZQ0KCQlp bmQ6CWluZHVjdG9yDQoJCWlzcmM6CWN1cnJlbnQgc291cmNlDQoJCWpmZXQ6 CUp1bmN0aW9uIEZFVA0KCQltZXM6CU1FUyBGRVQgKEdhQXMpDQoJCW1vczE6 CU1PUywgc2ltcGxlc3QgYW5hbHl0aWMgbW9kZWwsIGZhc3Rlc3QNCgkJbW9z MjoJTU9TLCBtaWRkbGUgY29tcGxleGl0eSBhbmQgYWNjdXJhY3kNCgkJbW9z MzoJTU9TLCBtb3N0IGNvbXBsaWNhdGVkLCBtb3N0IGFjY3VyYXRlDQoJCW1v czY6IAlNT1MsIG5ldywgZmFzdCBhbmFseXRpYywgc2hvcnQtY2hhbm5lbA0K CQlyZXM6CXJlc2lzdG9yDQoJCXN3Oglzd2l0Y2gNCgkJdHJhOglsb3NzbGVz cyB0cmFuc21pc3Npb24gbGluZQ0KCQl1cmM6CXVuaWZvcm0gUkMgbGluZQ0K CQl2Y2NzOgl2b2x0YWdlLWNvbnRyb2xsZWQgY3VycmVudCBzb3VyY2UNCgkJ dmN2czoJdm9sdGFnZS1jb250cm9sbGVkIHZvbHRhZ2Ugc291cmNlDQoJCXZz cmM6CXZvbHRhZ2Ugc291cmNlDQoNCglUaGUgZm9sbG93aW5nIGlzIHRoZSBj b3JyZXNwb25kaW5nIGxpc3Qgb2YgYW5hbHlzZXM6DQoJCW9wOglEQyBvcGVy YXRpbmcgcG9pbnQNCgkJZGM6CURDIHRyYW5zZmVyIGN1cnZlDQoJCXRmOglT bWFsbCBzaWduYWwgdHJhbnNmZXIgZnVuY3Rpb24NCgkJYWM6CUFDIChmcmVx dWVuY3kgZG9tYWluKQ0KCQl0cmFuOgl0cmFuc2llbnQNCgkJcHo6CXBvbGUt emVybw0KCQlkaXN0bzoJZGlzdG9ydGlvbg0KCQlub2lzZToJbm9pc2UNCgkJ c2Vuc2U6CXNlbnNpdGl2aXR5DQoNCg0KDQpUZWNobmljYWwgUHJvYmxlbXMN Cg0KCVNwaWNlIG5vIGxvbmdlciBoYXMgdGVjaG5pY2FsIHN1cHBvcnQgZnJv bSB0aGUNCglVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuICBJZiB5b3UgaGF2 ZSBwcm9ibGVtcyB3aXRoIHRoZQ0KCW1lZGlhIG9yIHF1ZXN0aW9ucyBhYm91 dCBvcmRpbmcgc3BpY2UzLCB5b3UgbWF5IHNlbmQgZW1haWwgdG86DQoNCgkJ c29mdHdhcmVAZWVjcy5iZXJrZWxleS5lZHUNCg0KCW9yICh2aWEgVVMgTWFp bCk6DQoNCgkJRUVDUy9FUkwgSW5kdXN0cmlhbCBTdXBwb3J0IE9mZmljZQ0K CQlBdHRuOiBTcGljZSBUZWNobmljYWwgUXVlc3Rpb24NCgkJMjA1IENvcnkg SGFsbA0KCQlVLkMuIEJlcmtlbGV5DQoJCUJlcmtlbGV5LCBDQSAgIDk0NzIw DQoNCglQYXRjaGVzIGZvciBzb21lIHByZXZpb3VzIHZlcnNpb24gb2Ygc3Bp Y2UzIGFyZSBhdmFpbGFibGUgdmlhDQoJYW5vbnltb3VzIGZ0cCBmcm9tIGlj LmJlcmtlbGV5LmVkdSwgaW4gdGhlIHN1YmRpcmVjdG9yeSAicHViL3NwaWNl My8iLg0KDQo= --0-1239222546-816974341=:598-- From owner-freebsd-ports Tue Nov 21 20:57:45 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA01581 for ports-outgoing; Tue, 21 Nov 1995 20:57:45 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA01576 for ; Tue, 21 Nov 1995 20:57:41 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id UAA01904; Tue, 21 Nov 1995 20:57:26 -0800 Date: Tue, 21 Nov 1995 20:57:26 -0800 Message-Id: <199511220457.UAA01904@silvia.HIP.Berkeley.EDU> To: gena@NetVision.net.il CC: ports@FreeBSD.org In-reply-to: (message from Gennady Sorokopud on Tue, 21 Nov 1995 16:39:08 IST) Subject: Re: xfmail-0.3 From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@FreeBSD.org Precedence: bulk * Xfmail-0.3 finally has been released, and i update port's Makefile * to reflect the changes (they are minor). * * Please put this new Makefile to the ports tree. Thanks, committed. I also added files/md5 (checksum). Satoshi From owner-freebsd-ports Tue Nov 21 21:58:10 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA06434 for ports-outgoing; Tue, 21 Nov 1995 21:58:10 -0800 Received: from wink.io.org (root@wink.io.org [198.133.36.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA06428 for ; Tue, 21 Nov 1995 21:58:06 -0800 Received: from flinch (flinch.io.org [198.133.36.153]) by wink.io.org (8.6.9/8.6.9) with SMTP id AAA13666 for ; Wed, 22 Nov 1995 00:57:59 -0500 Date: Wed, 22 Nov 1995 00:57:14 -0500 (EST) From: Brian Tao X-Sender: taob@flinch To: FREEBSD-PORTS-L Subject: TeX 3.1415 + LaTeX2e.9506 packages not correct? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk I wanted to get LaTeX2e up and running on a new machine ASAP, so I pkg_added the TeX and LaTeX2e packages from the 2.1 collection. When I tried to latex a file, I got some error to the effect of "Bad format file error. I'm stymied." I'm vague on the error because I just removed the package and I plan to rebuilt it all from sources anyway. Has anyone else run into this problem? -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-ports Tue Nov 21 22:17:42 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA07154 for ports-outgoing; Tue, 21 Nov 1995 22:17:42 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA07149 for ; Tue, 21 Nov 1995 22:17:29 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id GAA25100; Wed, 22 Nov 1995 06:15:35 GMT From: Michael Smith Message-Id: <199511220615.GAA25100@genesis.atrad.adelaide.edu.au> Subject: Re: Proposal 3: Non-executable file in *_DEPEND To: asami@cs.berkeley.edu (Satoshi Asami) Date: Wed, 22 Nov 1995 06:15:35 +0000 () Cc: msmith@atrad.adelaide.edu.au, ports@FreeBSD.ORG In-Reply-To: <199511201353.FAA01006@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 20, 95 05:53:02 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2321 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Satoshi Asami stands accused of saying: > * if item not installed and port available > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This is the hard part. There is no easy way to get this mapping, > unlike port -> package. The only file that contains this, > /usr/ports/INDEX, is often out of date, not only because of my > laziness, but also because we can't expect the users to grab that file > off the ftp site too often. No, but if "find /usr/ports -name -type d" comes up with exactly one match, or (perhaps better) a traversal of the Makefiles in /usr/ports finds the offender, you've got it. It's nontrivial, but it is possible. >* to put some coherent thoughts together. I spent a little time recently >* looking at how the RedHat Linux people do things. They're a little more >* rigid in their pacakge definition rules, but the "rpm" tools looked >* fairly similar in feature set to the pkg_* tools, so I tinkered with >* their graphical front end with a vague idea to making it work under FreeBSD. > > That's very cool. Not really 8( They use Python with a pile of nonstandard options to provide the GUI. I had some prompt and to-the-point help (fortunately) on Python, or it would have been a very short tinker 8( > * Because a hypothetical interactive installer will pop up a dialog and say > > Yeah, that will be nice.... Well, I think there are a number of people who might be willing to spend some time writing a nice frontend; I'm currently reasonably enthused about doing some work on a "pkg" tool, given that most of my other "great ideas" have stonewalled 8( > This is already recommended, although not mandatory. I'm planning tho > bring this up as "proposal 5" or something. :) Of curiosity, have you ever looked at "setld" under Ultrix? (OSF/1?) It's one of the most horrific pieces of sh programming I've ever met, but it really sets the basic standard for what we need. > Satoshi -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-ports Wed Nov 22 04:09:26 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA02983 for ports-outgoing; Wed, 22 Nov 1995 04:09:26 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA02969 for ; Wed, 22 Nov 1995 04:09:18 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id EAA03464; Wed, 22 Nov 1995 04:09:09 -0800 Date: Wed, 22 Nov 1995 04:09:09 -0800 Message-Id: <199511221209.EAA03464@silvia.HIP.Berkeley.EDU> To: ports@freebsd.org Subject: Proposal 4: new category "www" From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@freebsd.org Precedence: bulk As per Paul (that's pst)'s request, I think we should make a new category "www". I'll drop my idea of "net-www" or whatever, it occurred to me that "news" and "mails" are subsets of "net" too, and we aren't calling them "net-news" or "net-mails". :) I prefer "www" over "web", it's clearer what it means and I know nobody likes to pronunce it, but hey it's spelled "www" but pronounced "web". :) Also, given the fact that there are half a zillion "www.foo.com" but only a few "web.bar.com"s, I don't think it's any doubt which is the more accepted acronym (ok, "web" isn't an acronym in the first place, but you get the idea). I think the following can form the initial membership of this new (but already big) category: Mosaic, apache, cern_httpd, cern_linemode, chimera, gn, lynx, netscape, netscape2, tkWWW, wn, wwwish, zircon (from "net") ashe, tkHTML (from "editors") weblint (from "devel") I'm not sure about "gn", as it's both a www and gopher server, but I think it's fine to put it in "www", people looking for it should have no trouble finding it here, no? Satoshi P.S. Looking through /usr/ports/net, I notice there are quite a few ports pertaining to (1) network video, (2) gopher, and (3) file transfer but I don't think any of them warrant a new category yet. From owner-freebsd-ports Wed Nov 22 04:53:22 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA06721 for ports-outgoing; Wed, 22 Nov 1995 04:53:22 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA06709 for ; Wed, 22 Nov 1995 04:53:18 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id EAA04903; Wed, 22 Nov 1995 04:53:15 -0800 Date: Wed, 22 Nov 1995 04:53:15 -0800 Message-Id: <199511221253.EAA04903@silvia.HIP.Berkeley.EDU> To: ports@freebsd.org Subject: Proposal 3 first cut -- depending on non-executables From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@freebsd.org Precedence: bulk Please try the following patch (relative to -current). Now you should be able to depend on a non-executable in {FETCH,BUILD,RUN}_DEPENDS. Just specify the full pathname (you can use ${PREFIX} and such) instead of the command name. bsd.port.mk will detect the "/" at the beginning and use a "test -e" instead of "which -s". You can even depend on a directory name (although the message still says "file"). The side effect of this is that if you really depend on an executable which is in a non-standard place (thus you need a full pathname), and the file is there but without the execute permission, it will (erroneously) think everything's fine and the build will fail. But I don't think we have to worry about such a pathological case. ;) Satoshi ------- Index: bsd.port.mk =================================================================== RCS file: /usr/cvs/src/share/mk/bsd.port.mk,v retrieving revision 1.187 diff -u -r1.187 bsd.port.mk --- bsd.port.mk 1995/11/17 16:49:40 1.187 +++ bsd.port.mk 1995/11/22 12:41:31 @@ -1005,16 +1005,34 @@ @for i in ${DEPENDS_TMP}; do \ prog=`/bin/echo $$i | /usr/bin/sed -e 's/:.*//'`; \ dir=`/bin/echo $$i | /usr/bin/sed -e 's/.*://'`; \ - ${ECHO_MSG} "===> ${PKGNAME} depends on executable: $$prog ($$dir)"; \ + if expr "$$prog" : \\/ >/dev/null; then \ + ${ECHO_MSG} "===> ${PKGNAME} depends on file: $$prog ($$dir)"; \ + else \ + ${ECHO_MSG} "===> ${PKGNAME} depends on executable: $$prog ($$dir)"; \ + fi; \ done .else @for i in ${DEPENDS_TMP}; do \ prog=`/bin/echo $$i | /usr/bin/sed -e 's/:.*//'`; \ dir=`/bin/echo $$i | /usr/bin/sed -e 's/.*://'`; \ - if which -s "$$prog"; then \ - ${ECHO_MSG} "===> ${PKGNAME} depends on executable: $$prog - found"; \ + if expr "$$prog" : \\/ >/dev/null; then \ + if [ -e "$$prog" ]; then \ + ${ECHO_MSG} "===> ${PKGNAME} depends on file: $$prog - found"; \ + notfound=0; \ + else \ + ${ECHO_MSG} "===> ${PKGNAME} depends on file: $$prog - not found"; \ + notfound=1; \ + fi; \ else \ - ${ECHO_MSG} "===> ${PKGNAME} depends on executable: $$prog - not found"; \ + if which -s "$$prog"; then \ + ${ECHO_MSG} "===> ${PKGNAME} depends on executable: $$prog - found"; \ + notfound=0; \ + else \ + ${ECHO_MSG} "===> ${PKGNAME} depends on executable: $$prog - not found"; \ + notfound=1; \ + fi; \ + fi; \ + if [ $$notfound != 0 ]; then \ ${ECHO_MSG} "===> Verifying build for $$prog in $$dir"; \ if [ ! -d "$$dir" ]; then \ ${ECHO_MSG} ">> No directory for $$prog. Skipping.."; \ From owner-freebsd-ports Wed Nov 22 05:30:11 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA11604 for ports-outgoing; Wed, 22 Nov 1995 05:30:11 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA11593 for ; Wed, 22 Nov 1995 05:30:04 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id FAA05009; Wed, 22 Nov 1995 05:30:01 -0800 Date: Wed, 22 Nov 1995 05:30:01 -0800 Message-Id: <199511221330.FAA05009@silvia.HIP.Berkeley.EDU> To: ports@freebsd.org Subject: Proposal 5: utils -> misc From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@freebsd.org Precedence: bulk The category "utils" has never lived up to its expectation where people put in all sort of useful utilities -- in fact, most of the things in the ports tree is a great utility in one way or another! :) And this naming is confusing at best, so I suggest changing it to "misc". That way it will be much clearer that it's not really a category on its own right, but sort of a "catch-all" for things that don't really belong elsewhere (and looking at the current population, this is what they exactly are). We can also move games/astrolog in accordance to Andrey's old complaint. :) Satoshi From owner-freebsd-ports Wed Nov 22 08:04:20 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA21542 for ports-outgoing; Wed, 22 Nov 1995 08:04:20 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA21391 for ; Wed, 22 Nov 1995 08:03:57 -0800 Received: by sequent.kiae.su id AA11659 (5.65.kiae-2 ); Wed, 22 Nov 1995 18:49:48 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 22 Nov 95 18:49:45 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.12/8.6.12) id SAA00673; Wed, 22 Nov 1995 18:48:30 +0300 To: Satoshi Asami Cc: CVS-commiters@freefall.freebsd.org, cvs-ports@freefall.freebsd.org, ports@freebsd.org References: <199511221131.DAA03320@silvia.HIP.Berkeley.EDU> In-Reply-To: <199511221131.DAA03320@silvia.HIP.Berkeley.EDU>; from Satoshi Asami at Wed, 22 Nov 1995 03:31:40 -0800 Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 22 Nov 1995 18:48:29 +0300 (MSK) X-Mailer: Mail/@ [v2.41 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: cvs commit: ports/mail/elm/scripts pre-configure Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1391 Sender: owner-ports@freebsd.org Precedence: bulk In message <199511221131.DAA03320@silvia.HIP.Berkeley.EDU> Satoshi Asami writes: > * Modified: mail/elm Makefile >Thanks, but it doesn't compile on thud. > : >Should support for MIME be compiled in? [n] >Should PGP (Pretty Good Privacy) support be compiled in? [y] Where is the pgp binary located? [/usr/local/bin/pgp] File /usr/local/bin/pgp doesn't exist. Use that name anyway? [n] Where is the pgp binary located? [n] Please give the full pathname. >Should we add BUILD_DEPENDS and RUN_DEPENDS on pgp or something? I am stuck on this issue somehow. Basically following Elm configurations takes sense: Elm without MIME and without PGP Elm without MIME and with PGP: RUN_DEPENDS = pgp Elm with MIME and without PGP: RUN_DEPENDS = metamail Elm with MIME and with PGP: RUN_DEPENDS = pgp & metamail When user run make it can be easily handled via environment variables f.e. But it seems that we need to build 4 different Elm packages in any case, so user tuning doesn't take much sense. So, we need 4 different directories for Elm in 'mail' subdir. Does anybody have better idea? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-ports Wed Nov 22 08:35:45 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA24061 for ports-outgoing; Wed, 22 Nov 1995 08:35:45 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA24054 for ; Wed, 22 Nov 1995 08:35:36 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id IAA03054; Wed, 22 Nov 1995 08:35:08 -0800 To: Michael Smith cc: asami@cs.berkeley.edu (Satoshi Asami), ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND In-reply-to: Your message of "Wed, 22 Nov 1995 06:15:35 GMT." <199511220615.GAA25100@genesis.atrad.adelaide.edu.au> Date: Wed, 22 Nov 1995 08:35:08 -0800 Message-ID: <3052.817058108@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-ports@FreeBSD.ORG Precedence: bulk > Well, I think there are a number of people who might be willing to spend some > time writing a nice frontend; I'm currently reasonably enthused about doing > some work on a "pkg" tool, given that most of my other "great ideas" have > stonewalled 8( > > > This is already recommended, although not mandatory. I'm planning tho > > bring this up as "proposal 5" or something. :) > > Of curiosity, have you ever looked at "setld" under Ultrix? (OSF/1?) It's > one of the most horrific pieces of sh programming I've ever met, but it > really sets the basic standard for what we need. OK, here's my take on what needs to be done: 1. The existing package format loses and needs to die. More on that in a moment. 2. We need a very simple 3D filesystem library (yes, *library*). 3. We need a box of GUI tools. 4. We need applications to paper over all these clever mechanisms. --- 1. The existing package format needs to die for several reasons, the foremost being: o The "plist" syntax loses, lacks conditionals, is arcane, does not handle checksum verification, preserves insufficient information for proper deletion, sucks, is evil, gag, retch, puke. o Having the packages be gzip'd tarballs does not allow sufficient random access and requires hateful amounts of temporary storage. This is why there are "distributions" and there are "packages" and the twain have never met. That bites, because they're both different solutions for the same problem. o The idea of letting packages do their installation magic via shell scripts was one of the stupid ideas in the known universe. Yes, it's very convenient, but it's also a MASSIVELY LOSING SECURITY HOLE! One little package is capable of reducing your system to a smoking crater at its merest whim, or it can decide to be spiteful and trojan-horse you up the wazoo! Since packages aren't "signed" in any special way, you don't even know if the package you see on that archive is one of ours, or one of "theirs." That goes beyond evil - that is evil incarnate. o Too many other reasons to mention. Everything under /usr/src/usr.sbin/pkg_install needs to be toasted with a flamethrower, the remains of the disk it was on bombarded with hard gamma radiation, crushed into tiny fragments and dumped like confetti over the north sea. This code is *begging* to die. So what to put in its place? Well, I have some ideas. For one thing, the PLIST needs to go away and be replaced by a genuine interpreted language. I'm not saying forth, I'm not even saying TCL (though it sounds promising), maybe even my little C interpreter since I got it going again - it does a lot of things that TCL doesn't do, like compile and run on a virtual machine. In any case, the important thing is to make plists much more flexible, eliminate the idea of external require/install/deinstall scripts and use the language instead (so that you can do the equivalent of safe-tcl and declare certain operations off-limits for untrusted packages). We can also bolt in concepts like MD5 conflict detection and such a lot more easily with a system like this. Secondly, the package format itself needs to support the idea of extracting just the bootstrap segment or description info from the package (quickly) and allowing the bootstrap to unpack the package directly in-place (or through the 3DFS library) without going through an intermediate directory. Many of these component technologies could be worked on separately by different people (in fact, I almost recommend it) and then assembled into a complete system. 2. A very simple 3D filesystem library. What is he *talking* about? Don't worry - it's not as complicated as it sounds. Consider, for a moment, the life of your average /usr/local or /usr/src directory. Things come in and out, are updated, sometimes an update turns out to be a pain so we back off again, etc. The interdependencies that exist (e.g. /usr/X11R6/bin/fvwm depends on /usr/X11R6/lib/libXpm.so.3.4) also aren't really described in the filesystem, they're someplace else (either somebody's head, a Makefile or a package). This forces all tools to reinvent the wheel when it comes to keeping track of what they've done and who they depend on, and it leads to failure-prone implementations that only do crude first approximations of journaling, like the one in pkg_install. Since we're going to be right back at this point again the minute we start doing real patch maintainance on top of our releases, and we'd also really like to just shove all this stuff together so that the distinction between installing "distributions" and installing "packages" disappears anyway, what we really need is a unified solution for everything from /usr/X11R6 to /usr/src to /usr/bin (yes! binary updates!). Here's what I recommend: We implement a simple 3D filesystem model where it's possible to set the "pointer" on a filesystem (or some sub-section thereof) to any point in time using the 3DFS API. The pointer could be absolute, meaning that it caused the master copy to be changed, or it could be relative to a link tree created as a "shadow" of the master. Time stamp information would come out of a central database at the top of the tree, or some location specified by environment variable. The delta (history) information would be stored in the tree itself, with each directory containing the "undo" information required to roll back any file. I'll attempt to explain this in more detail: Let's say you have /usr/src under control of the 3DFS - you've called ``3dfs_init("/usr/src")'', or whatever API library call is provided for the purpose, and now there's a /usr/src/.3DFS file in place (note: I'm not saying it'd have to live there - I can see designing this to allow all of it to take place in a completely different dir as well). Now say you want to install the next version of the FreeBSD src distribution *splat* right on top, but you have the disk space to spare and you'd like to be able to get back to (or even just compare with) the previous version. Well, since the FreeBSD src dist would now be a number of "packages" in the newer scheme of things, the package adder would call a 3DFS API call for each prefix dir it was about to attack and essentially say "*knock* *knock* Can I come in? I have all these file updates for you under the heading `RELENG_2_1_1'." The 3DFS library would search for all the requisite database files, making sure it could lock and write to them, verify that the key was unique, and if all was cool and groovy it would say: "Sure! But be sure to use *my* API calls now for actually copying stuff into place!" The package installer would then assume a "hands off" approach to things under that prefix and hand 3DFS the file updates though a pipe created for that purpose by the API (anyone having better suggestions for avoiding temp files is welcome to contact me). The 3DFS code would look at the proposed file and calculate how best to store an "undo" record between the current version and the proposed version. If the change was really small, it might generate a context diff internally. If the change description was bigger than the file, it'd just save the old file entirely (like the old patch kit used to do). In any case, the 3DFS would handle all the sticky details of making sure you could move back to a previous state. It would also store dependency information for you, so you could choose to have things blip out of existance if something they depended upon was invalidated by the pointer position (or perform some other trickery). More on the sticky details? OK. The 3DFS's database would (at first ponder) consist of entries like this: +--------------------+ | textual description| +--------------------+ | date stamp | +--------------------+ | unique hash key | +--------------------+ | previous delta | +--------------------+ | misc info on entry | +--------------------+ | file spec 1 | +--------------------+ | ... | +--------------------+ | file spec n | +--------------------+ Each "event" description would be checked for uniqueness and the date verified (so we don't trash our database by somebody's screwed up clock :-) before being added to the locked database. We'd also use the date and/or event description to generate a unique 8 character base 36 "key" that describes the event uniquely. This key will be used for, among other things, generating the filename containing the change info between the "previous delta" and this one. If no previous delta exists, this change can be assumed to be a base delta. The delta files would exist under a shadow structure of the tree being managed by 3DFS, e.g. you might see something like: /usr/src/bin/ls/.3ddelta/ls.c/3A97qflz /usr/src/bin/ls/.3ddelta/ls.c/1291rmPd /usr/src/bin/ls/.3ddelta/ls.1/1291rmPd If ls.c and ls.1 had been changed in one revision (hashed by "1291rmPd") and then ls.c changed in a subsequent revision ("3A97qflz"). For tracing back this kind of information more easily, we'll have some sort of `3dlog' command that ferrets it out and looks it up for any given point in the tree. In any case, the important thing is that we be able to have the equivalent of CVS but for any file on the system, be it in /usr/local/bin or /usr/src/bin, and with more of an emphasis on *other* things changing your tree, not you the developer changing it. Implementing 3DFS will give us package removals that finally work and dependency records that actually don't require leaping around and trying to update multiple files (as pkg_add currently does). Best of all, none of these tools will have to sweat the details of roll-back - they'll just use the 3DFS API to make that code do all the work. Maybe we'll even get a new and improved patch kit out of this! :-) This is also actually just the vaguest description of 3DFS, and I've written it out in quite a bit more detail than this (I haven't even covered compaction, etc). But my fingers are already tired today, so anyone really interested in this is encouraged to contact me directly. There is still much work to be done on the *implementation* of this! :-) 3. We need a box of GUI tools. Yes, I'll say it until I'm blue. We need a replacement for libdialog and a bunch of other stuff besides! We need scrolling lists and pull down menus and frames and row-column layout managers and a whole host of things that the Windows weenies take for granted now. We need these so that we can construct the next-generation system installation and management system that the world has been crying out for, and so that we can properly front-end the packages we have. If you noticed any quick and obvious differences between pkg_manage and sysinstall's package menus, you probably noticed the fact that pkg_manage has horrible navigation but good description and extraction help, whereas sysinstall's package menus had *better* navigation (still not very good) but horrible description and extraction detail (read: none). In both cases, this is largely the result of poor GUI tools. We just don't have the objects available to do the kinds of things we need! Scrolling lists and pull-down menus would certainly do the fdisk and label screens in sysinstall a world of good, if nothing else! This could be done by any reasonably competent ncurses hacker. That would not, unfortunately, include me! :-( Would someone care to perhaps write an ncurses *abstraction* layer for someone like me, so I wouldn't have to figure out how to draw things out of the line drawing character set or properly refresh regions uncovered by pull-down menus? :-) If that were done, I could actually see doing the rest. Just so I don't need to know anything really deep about ncurses to actually draw the objects. This needs to be abstracted *anyway*, actually, so that we can do this under X too when the time comes. 4. We need applications to paper over all these clever mechanisms. Naturally, pkg_add, pkg_delete and friends will have to be re-written to take advantage of all these nice building blocks. So will sysinstall. I don't mind. :-) We will also want to have new commands for reporting on 3DFS information, reclaiming space, invalidating deltas, etc. I don't mind working on a lot of this, if I can get some help! We also need a specification format for the various GUI screens, since nobody wants to hack that stuff out in raw C if they can help it. Does this mean libforms? Something else? Comments? Jordan From owner-freebsd-ports Wed Nov 22 11:42:35 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA05646 for ports-outgoing; Wed, 22 Nov 1995 11:42:35 -0800 Received: from chemserv.umd.edu (chemserv.umd.edu [129.2.64.40]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA05630 for ; Wed, 22 Nov 1995 11:42:25 -0800 Received: from espresso.eng.umd.edu (espresso.eng.umd.edu [129.2.98.13]) by chemserv.umd.edu (8.7.1/8.7) with ESMTP id OAA22583; Wed, 22 Nov 1995 14:42:22 -0500 (EST) Received: (chuckr@localhost) by espresso.eng.umd.edu (8.7/8.6.4) id OAA08561; Wed, 22 Nov 1995 14:42:21 -0500 (EST) Date: Wed, 22 Nov 1995 14:42:21 -0500 (EST) From: Chuck Robey X-Sender: chuckr@espresso.eng.umd.edu To: Satoshi Asami cc: ports@FreeBSD.ORG Subject: Re: Proposal 5: utils -> misc In-Reply-To: <199511221330.FAA05009@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@FreeBSD.ORG Precedence: bulk On Wed, 22 Nov 1995, Satoshi Asami wrote: > The category "utils" has never lived up to its expectation where > people put in all sort of useful utilities -- in fact, most of the > things in the ports tree is a great utility in one way or another! :) > > And this naming is confusing at best, so I suggest changing it to > "misc". That way it will be much clearer that it's not really a > category on its own right, but sort of a "catch-all" for things that > don't really belong elsewhere (and looking at the current population, > this is what they exactly are). > > We can also move games/astrolog in accordance to Andrey's old > complaint. :) I don't see any reason not to let you do what you want, but this change seems to be a little more gratuitous than all the rest. I mean, like you say, everything is Unix is a utility, so I don't see where "misc" gives any more or less info to users than "utils". > > Satoshi > ============================================================================ Chuck Robey chuckr@eng.umd.edu -- I run FreeBSD on n3lxx and Journey2 --------------------------------------------------------------------------- The Dilbert Zone is Dilbert's new WWW home! The area features never-before-seen original sketches of Dilbert, a photo tour of Scott Adams' studio, Dilbert Trivia and memorabilia, high school photos and much more!: From owner-freebsd-ports Wed Nov 22 13:13:28 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA12012 for ports-outgoing; Wed, 22 Nov 1995 13:13:28 -0800 Received: from maui.com (langfod@waena.mrtc.maui.com [199.4.33.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA12006 for ; Wed, 22 Nov 1995 13:13:22 -0800 Received: (from langfod@localhost) by maui.com (8.6.10/8.6.6) id LAA11608; Wed, 22 Nov 1995 11:16:54 -1000 From: David Langford Message-Id: <199511222116.LAA11608@ maui.com> Subject: Re: cvs commit: ports/mail/elm/scripts pre-configure To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Wed, 22 Nov 1995 11:16:54 -1000 (HST) Cc: ports@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Nov 22, 95 06:48:29 pm X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1546 Sender: owner-ports@freebsd.org Precedence: bulk >I am stuck on this issue somehow. Basically following Elm configurations >takes sense: > >Elm without MIME and without PGP >Elm without MIME and with PGP: RUN_DEPENDS = pgp >Elm with MIME and without PGP: RUN_DEPENDS = metamail >Elm with MIME and with PGP: RUN_DEPENDS = pgp & metamail > >When user run make it can be easily handled via >environment variables f.e. But it seems that we need to build >4 different Elm packages in any case, so user tuning doesn't >take much sense. >So, we need 4 different directories for Elm in 'mail' subdir. >Does anybody have better idea? I have been wondering for awhile if it would be possible to get make to ASK the user a few simple questions. In the case of Elm it would ask if the user wants the MIME, PGP or MIME+PGP port to be built. (Yes, this is what configure is for but we are trying to make it easy- if someone really wants to do things differently then that can run configure themselves) There are a number of programs that have features that could be compiled in but may not be wanted by all users. This may get a little comlicated as the answer may then require new packages to be installed. I have a couple of ports on back burner that this would be useful on... Just a thought. -- /--------------------------------------------------------------------\ | David Langford - Kihei, Maui, Hawaii - langfod@maui.com | | Maui Research and Technology Center -- Network Administrator | \--------------------------------------------------------------------/ From owner-freebsd-ports Wed Nov 22 14:28:27 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA16461 for ports-outgoing; Wed, 22 Nov 1995 14:28:27 -0800 Received: from forgery.CS.Berkeley.EDU (forgery.CS.Berkeley.EDU [128.32.33.75]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA16454 for ; Wed, 22 Nov 1995 14:28:23 -0800 Received: (from asami@localhost) by forgery.CS.Berkeley.EDU (8.6.11/8.6.9) id OAA19821; Wed, 22 Nov 1995 14:28:17 -0800 Date: Wed, 22 Nov 1995 14:28:17 -0800 Message-Id: <199511222228.OAA19821@forgery.CS.Berkeley.EDU> To: chuckr@glue.umd.edu CC: ports@FreeBSD.ORG In-reply-to: (message from Chuck Robey on Wed, 22 Nov 1995 14:42:21 -0500 (EST)) Subject: Re: Proposal 5: utils -> misc From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-ports@FreeBSD.ORG Precedence: bulk * I don't see any reason not to let you do what you want, but this change * seems to be a little more gratuitous than all the rest. I mean, like you * say, everything is Unix is a utility, so I don't see where "misc" gives * any more or less info to users than "utils". One, it will let porters think once more before adding stuff to it. It wasn't a long time before it filled up and "sysutils" and "emulators" were spawned off, and it's starting to grow again! Two, it will provide a "catch-all" for things that truly don't belong elsewhere, like "astrolog". Satoshi From owner-freebsd-ports Wed Nov 22 14:44:50 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA17514 for ports-outgoing; Wed, 22 Nov 1995 14:44:50 -0800 Received: from netcom11.netcom.com (root@netcom11.netcom.com [192.100.81.121]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA17509 for ; Wed, 22 Nov 1995 14:44:44 -0800 Received: from Ðãs’³6 Òsá$6¢ÒsP by netcom11.netcom.com (8.6.12/Netcom) id OAA15150; Wed, 22 Nov 1995 14:42:53 -0800 Date: Wed, 22 Nov 1995 14:42:53 -0800 Message-Id: <199511222242.OAA15150@netcom11.netcom.com> X-Mailer: NCSA Mosaic/2.0 (Windows x86) X-URL: http://www.freebsd.org/ports/news.html From: rjiang@akbs.com (Ruiyuan Jiang) To: ports@FreeBSD.ORG Subject: Trying to download the CNews Description file Sender: owner-ports@FreeBSD.ORG Precedence: bulk Hi, I tried several times to download the CNews and NNTP description file and I never got successful. Can you mail the description file to me, please? Also if I install the CNews, do I need the NNTP transport? We have 56 kbps frame realy line to connect to internet (not UUCP). I read the book "Managing UUCP and Usenet". It mentions that CNews needs NNTP transport. Thanks in advance. Ruiyuan Jiang System Administrator Advantage kbs, Inc. rjiang@akbs.com (908) 287-2236 From owner-freebsd-ports Wed Nov 22 17:17:18 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00522 for ports-outgoing; Wed, 22 Nov 1995 17:17:18 -0800 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA00517 for ; Wed, 22 Nov 1995 17:17:14 -0800 Received: by sovcom.kiae.su id AA12899 (5.65.kiae-1 ); Thu, 23 Nov 1995 04:12:52 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Thu, 23 Nov 95 04:12:52 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.12/8.6.12) id EAA00997; Thu, 23 Nov 1995 04:06:37 +0300 To: David Langford Cc: ports@freebsd.org References: <199511222116.LAA11608@ maui.com> In-Reply-To: <199511222116.LAA11608@ maui.com>; from David Langford at Wed, 22 Nov 1995 11:16:54 -1000 (HST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 23 Nov 1995 04:06:37 +0300 (MSK) X-Mailer: Mail/@ [v2.41 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: cvs commit: ports/mail/elm/scripts pre-configure Lines: 36 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1553 Sender: owner-ports@freebsd.org Precedence: bulk In message <199511222116.LAA11608@ maui.com> David Langford writes: >>I am stuck on this issue somehow. Basically following Elm configurations >>takes sense: >> >>Elm without MIME and without PGP >>Elm without MIME and with PGP: RUN_DEPENDS = pgp >>Elm with MIME and without PGP: RUN_DEPENDS = metamail >>Elm with MIME and with PGP: RUN_DEPENDS = pgp & metamail >> >>When user run make it can be easily handled via >>environment variables f.e. But it seems that we need to build >>4 different Elm packages in any case, so user tuning doesn't >>take much sense. >>So, we need 4 different directories for Elm in 'mail' subdir. >>Does anybody have better idea? >I have been wondering for awhile if it would be possible to get make to >ASK the user a few simple questions. >In the case of Elm it would ask if the user wants the MIME, PGP or MIME+PGP >port to be built. (Yes, this is what configure is for but we are trying >to make it easy- if someone really wants to do things differently then >that can run configure themselves) It seems that you miss the point. Asking any amount of questions not saves from building 4 different packages, so if I forced to build them I don't need to ask any questions at all. Remember: package can't ask any questions. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-ports Wed Nov 22 17:22:05 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00870 for ports-outgoing; Wed, 22 Nov 1995 17:22:05 -0800 Received: from maui.com (langfod@waena.mrtc.maui.com [199.4.33.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00865 for ; Wed, 22 Nov 1995 17:22:00 -0800 Received: (from langfod@localhost) by maui.com (8.6.10/8.6.6) id PAA19462; Wed, 22 Nov 1995 15:26:03 -1000 From: David Langford Message-Id: <199511230126.PAA19462@ maui.com> Subject: Re: cvs commit: ports/mail/elm/scripts pre-configure To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Wed, 22 Nov 1995 15:26:03 -1000 (HST) Cc: langfod@maui.com, ports@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Nov 23, 95 04:06:37 am X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 875 Sender: owner-ports@freebsd.org Precedence: bulk >>In the case of Elm it would ask if the user wants the MIME, PGP or MIME+PGP >>port to be built. (Yes, this is what configure is for but we are trying >>to make it easy- if someone really wants to do things differently then >>that can run configure themselves) > >It seems that you miss the point. Asking any amount of questions >not saves from building 4 different packages, so if I forced to build >them I don't need to ask any questions at all. > >Remember: package can't ask any questions. Ahh yes. Point now well understood. *sigh* Life is just hard, sometimes. -- /--------------------------------------------------------------------\ | David Langford - Kihei, Maui, Hawaii - langfod@maui.com | | Maui Research and Technology Center -- Network Administrator | \--------------------------------------------------------------------/ From owner-freebsd-ports Wed Nov 22 17:23:07 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00979 for ports-outgoing; Wed, 22 Nov 1995 17:23:07 -0800 Received: from bacchus.eng.umd.edu (bacchus.eng.umd.edu [129.2.94.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00974 for ; Wed, 22 Nov 1995 17:23:03 -0800 Received: from cappuccino.eng.umd.edu (cappuccino.eng.umd.edu [129.2.98.14]) by bacchus.eng.umd.edu (8.7/8.7) with ESMTP id UAA20354; Wed, 22 Nov 1995 20:23:01 -0500 (EST) Received: (chuckr@localhost) by cappuccino.eng.umd.edu (8.7/8.6.4) id UAA14183; Wed, 22 Nov 1995 20:23:00 -0500 (EST) Date: Wed, 22 Nov 1995 20:22:59 -0500 (EST) From: Chuck Robey X-Sender: chuckr@cappuccino.eng.umd.edu To: Satoshi Asami cc: ports@FreeBSD.ORG Subject: Re: Proposal 5: utils -> misc In-Reply-To: <199511222228.OAA19821@forgery.CS.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@FreeBSD.ORG Precedence: bulk On Wed, 22 Nov 1995, Satoshi Asami wrote: > * I don't see any reason not to let you do what you want, but this change > * seems to be a little more gratuitous than all the rest. I mean, like you > * say, everything is Unix is a utility, so I don't see where "misc" gives > * any more or less info to users than "utils". > > One, it will let porters think once more before adding stuff to it. > It wasn't a long time before it filled up and "sysutils" and > "emulators" were spawned off, and it's starting to grow again! > > Two, it will provide a "catch-all" for things that truly don't belong > elsewhere, like "astrolog". OK. Semantics, I'd make a horrible salesman (such meanings don't make that much difference to me), but I understand. > > Satoshi > ============================================================================ Chuck Robey chuckr@eng.umd.edu -- I run FreeBSD on n3lxx and Journey2 --------------------------------------------------------------------------- The Dilbert Zone is Dilbert's new WWW home! The area features never-before-seen original sketches of Dilbert, a photo tour of Scott Adams' studio, Dilbert Trivia and memorabilia, high school photos and much more!: From owner-freebsd-ports Wed Nov 22 23:22:39 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA21109 for ports-outgoing; Wed, 22 Nov 1995 23:22:39 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA21097 for ; Wed, 22 Nov 1995 23:22:33 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id HAA28188; Thu, 23 Nov 1995 07:20:56 GMT From: Michael Smith Message-Id: <199511230720.HAA28188@genesis.atrad.adelaide.edu.au> Subject: Re: Proposal 3: Non-executable file in *_DEPEND To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 23 Nov 1995 07:20:56 +0000 () Cc: msmith@atrad.adelaide.edu.au, asami@cs.berkeley.edu, ports@FreeBSD.ORG In-Reply-To: <3052.817058108@time.cdrom.com> from "Jordan K. Hubbard" at Nov 22, 95 08:35:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8380 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard stands accused of saying: > OK, here's my take on what needs to be done: Argh! Jordan's finished 2.1 and needs a bigger mountain! 8) Seriously though, I guess if we want to do the thousand-pound package strategy, this isn't such a bad scenario. > 1. The existing package format needs to die for several reasons, the foremost > being: > > o The "plist" syntax loses, lacks conditionals, is arcane, > does not handle checksum verification, preserves insufficient > information for proper deletion, sucks, is evil, gag, retch, > puke. But it's simple. And the only one of the items above (it's two, really, if you count verification) that it loses on is the explicit list of files, sizes and times required for safe package deletions. > o Having the packages be gzip'd tarballs does not allow sufficient > random access and requires hateful amounts of temporary storage. > This is why there are "distributions" and there are "packages" > and the twain have never met. That bites, because they're both > different solutions for the same problem. True. We can wrap a package/distribution in another tarfile, and extend/ refrob/whatever the plist++ syntax to allow multiple tarballs inside the wrapper. You could then have safe multiple prefixes, and use tar -xf --fast-read --to-stdout tarball | (cd $prefix; tar -xzf -) to rip the tarball straight into its destination. We don't have perms files (ever seen a SCO package?), so this is potentially risky if anyone's silly enough to have users online at the time 8) > o Too many other reasons to mention. Everything under > /usr/src/usr.sbin/pkg_install needs to be toasted with a > flamethrower, the remains of the disk it was on bombarded with > hard gamma radiation, crushed into tiny fragments and dumped like > confetti over the north sea. This code is *begging* to die. You're too harsh. It makes for wonderful reading, and I've won several "you think _your_ toy language can be hard to read?" for K&R with that as a feature piece. > For one thing, the PLIST needs to go away and be replaced by a genuine > interpreted language. I'm not saying forth, I'm not even saying TCL Woooah mamma. Hold it _right_ there. Before we go writing InstallShield for FreeBSD (now _there's_ code that begs to die), let's have a look at what a package tool needs to do : 1) Add packages. 2) Remove packages. 3) Verify that a package is complete and correct. 4) Provide details on a package. -*-*-*- 4) You may want to know almost everything about a package : what it is, where it goes, what it requires, how big it is, who wrapped it, etc. 3) When the package is installed, a record of _everything_ that the package contained (files, sizes, timestamps, possibly config entries) should be made, so that it is possible to see what's been changed since the package was installed. Verifying a package should also mark the database for the package, to indicate that it was verified OK (or not). 2) Everything that comprises the package should be removed (optionally not if it was changed). Optionally, everything depending on the package should also die. 1) This is where the fun always is. Firstly, I can't see the real difference between a package and a port, apart from the process of producing the installed components from the supplied raw materials. I don't think that there _should_ be any difference, from the user's point of view. (Special cases such as interactive ports aside.) A package may have prerequisites, which should be installed recursively first. The files for a package should be extracted, avoiding overwriting anything, unless told to, and the placement of the files should be documented. Up to here, there's nothing requiring any scripting language, and we've covered a large proportion of the package population already. As far as I can see, the only thing that requires any "intelligence" in the whole process is frobbing system config files to (un)support the package in question. Given that most of these files are line- or field- based, adding a few relatively straightforward primitives (add this line/field, remove any lines/fields that look like this, etc) will bring our coverage close to 100%. Mind you, that's much less _fun_ 8) > (though it sounds promising), maybe even my little C interpreter since > I got it going again - it does a lot of things that TCL doesn't do, > like compile and run on a virtual machine. Complete sideline - where can I get this? > In any case, the important > thing is to make plists much more flexible, eliminate the idea of > external require/install/deinstall scripts and use the language > instead (so that you can do the equivalent of safe-tcl and declare > certain operations off-limits for untrusted packages). The only 'require' that should be valid is the presence/nonpresence of other packages. > We can also bolt in concepts like MD5 conflict detection and such a > lot more easily with a system like this. I think a PGP (or similar) -based package signature is _essential_. > Secondly, the package format itself needs to support the idea of > extracting just the bootstrap segment or description info from the > package (quickly) and allowing the bootstrap to unpack the package > directly in-place (or through the 3DFS library) without going through > an intermediate directory. > > Many of these component technologies could be worked on separately by > different people (in fact, I almost recommend it) and then assembled > into a complete system. The double-wrapped tarball would seem to do this ideally. Please do _not_ think about a proprietary file format - I spent too long unwrapping the stupid RedHat stuff just to get at their _source_code_ to think that it's a good idea. Inside the 'outer wrapper', you can put the script(s), icons, and one or more data-filled compressed tarballs containing components of the package. You could also reference tarballs _outside_ the wrapper, and thus hit the distfile concept on the head. > 2. A very simple 3D filesystem library. Neat. Lots of work, but possibly worth the effort. I can see us fielding a lot of questions from Lusers who have installed seventeen copies of emacs and filled up their "attic" filesystem though, and making the database smart enough to deal with damage caused by "2D" users/tools might be more work than the implementation itself. > This could be done by any reasonably competent ncurses hacker. That > would not, unfortunately, include me! :-( Death to character-mode interfaces! If people want text screens, they can have commandline-driven tools 8) We have an X server that will run on 16-colour VGA, on Herc-style mono cards, and who knows what else. This leaves users of async terminals and CGA cards out in the cold; both of these sorts would probably be quite happy with straightforward commandline tools. > about ncurses to actually draw the objects. This needs to be > abstracted *anyway*, actually, so that we can do this under X too > when the time comes. The time to start is _now_. > We also need a specification format for the various GUI screens, since > nobody wants to hack that stuff out in raw C if they can help it. > Does this mean libforms? Something else? Tk. Not because it's the best, or the easiest, or anything other than that it's _common_. On top of it, a set of form components and a form manager in whatever language wins (your Forth 'setup', Jordan?), that eats form specifications and generates appropriate form layouts : Title "Network Configuration" Field "Hostname", STRING, REQUIRED Field "IP Address", IPADDR, REQUIRED Field "Netmask", HEX(0-0xffffffff), REQUIRED Field "Nameserver", IPADDR, OPTIONAL Field "Gateway", IPADDR, OPTIONAL You could probably write a form manager for almost any interface that would swallow this, actually, my bias against text interfaces aside 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-ports Thu Nov 23 05:48:01 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA08146 for ports-outgoing; Thu, 23 Nov 1995 05:48:01 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA08129 for ; Thu, 23 Nov 1995 05:47:58 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id FAA19248; Thu, 23 Nov 1995 05:47:26 -0800 To: Michael Smith cc: asami@cs.berkeley.edu, ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND In-reply-to: Your message of "Thu, 23 Nov 1995 07:20:56 GMT." <199511230720.HAA28188@genesis.atrad.adelaide.edu.au> Date: Thu, 23 Nov 1995 05:47:26 -0800 Message-ID: <19246.817134446@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-ports@FreeBSD.ORG Precedence: bulk > Argh! Jordan's finished 2.1 and needs a bigger mountain! 8) Seriously though , > I guess if we want to do the thousand-pound package strategy, this isn't > such a bad scenario. To be honest, I've been thinking about this since long before 2.1 was even planned. This stuff is pretty old! :) > But it's simple. And the only one of the items above (it's two, really, if > you count verification) that it loses on is the explicit list of files, > sizes and times required for safe package deletions. Yes, the plist format is simple, which is why it evolved that way, but it has deeper problems. Consider, for example, the twistedness of @exec and @unexec, or the necessity for @dirrm, or the way that prefixes are handled, or even the gross specialized expansion of `%' directives to make up for the lack of any environment variable handling. I could go on. The number of special case hacks and kludges that were added after the initial plist syntax was defined is living proof, IMNSHO, that the original specification syntax was flawed. > True. We can wrap a package/distribution in another tarfile, and extend/ > refrob/whatever the plist++ syntax to allow multiple tarballs inside the > wrapper. You could then have safe multiple prefixes, and use > > tar -xf --fast-read --to-stdout tarball | (cd $prefix; tar -xzf -) I think it's simply time to go the DEC route, where you have multiple files comprising a package. Probably one or more foo.tgz files and a foo.inf file for each package. Yeah, it's messier and it knocks the paradigm of "one file per package" for a loop, but it make things a LOT easier across all the various media I'll need to support - think everything from floppies to FTP. > Woooah mamma. Hold it _right_ there. Before we go writing InstallShield > for FreeBSD (now _there's_ code that begs to die), let's have a look at > what a package tool needs to do : > > 1) Add packages. > 2) Remove packages. > 3) Verify that a package is complete and correct. > 4) Provide details on a package. 5) Deal with User Preferences 6) Deal with *other* packages 7) Possibly interact with the user 8) Possibly interact with higher level installation tools. 9) Be able to install system distributions 10) Be able to install packages by a very *wide* variety of means. It's a more complex problem that *just* what pkg_install provides. pkg_install is actually insufficient for the task in many respects and I wouldn't model the next generation tool after it. > 1) This is where the fun always is. Firstly, I can't see the real > difference between a package and a port, apart from the process of > producing the installed components from the supplied raw materials. I agree that a port install should still mimic a package install, however that's a different area of the problem. I'm just looking at merging packages and distributions right now. > Up to here, there's nothing requiring any scripting language, and we've > covered a large proportion of the package population already. You need the scripting language to talk to the user (conditionally), be more clever about wedging a package into place (there are many scenarios where a stupid install, like zircon, will just smash another port (like that tkcvs thing we used to have but seem to have wisely dropped) and render it inoperable. There are ways of merging two tcl applications (picking unique filenames, rebuilding index files, etc) but our current "blind, dumb robot" - the plist parser - doesn't know how to do any of those things and it wouldn't even be easy to train it. > [My C interpreter] > Complete sideline - where can I get this? Let me just finish my current code review on it and I'll release it again. In its previous incarnation, it was an X widget placement language (kind of like Tk and TCL cemented together) and I've always wanted to prise the functionality apart. > > 2. A very simple 3D filesystem library. > > Neat. Lots of work, but possibly worth the effort. Well, think more than packages - think "system upgrades" and I think you'll see why the chronological store becomes a lot more important. > I can see us fielding a lot of questions from Lusers who have installed > seventeen copies of emacs and filled up their "attic" filesystem though, > and making the database smart enough to deal with damage caused by "2D" > users/tools might be more work than the implementation itself. To be honest, I was thinking of doing a terrible thing (assuming I can get away with it): I was going to hack tar and cpio to recognise 3D file systems and let you specify "tag" information and such so that the extraction follows the 3DFS API. E.g.: tar -xvzf foo.tar --3dfstag MYREL_2_1 -C /my3dfs Could be made to DTRT. Other damage with 2D tools, well, I think we could at the very least have an options for: 1. Checking tree sanity, and if a checksum fails or a delta is found missing, report it and optionally try and fetch it from a known-good source. 2. Reconstructing the "visible" tree from scratch using some event tag. Both of these features would be really cool anyway and would deal with the long-standing problem of knowing whether that /usr/src you're looking at is *really* a good one, or if someone (maybe even sup) has spammed it. > Death to character-mode interfaces! If people want text screens, they can > have commandline-driven tools 8) We have an X server that will run on > 16-colour VGA, on Herc-style mono cards, and who knows what else. > This leaves users of async terminals and CGA cards out in the cold; both of > these sorts would probably be quite happy with straightforward commandline > tools. Now now, you forget one thing: I don't *like* writing command line interfaces! :-) Of course, I guess I could always expand the "script" mechanism from 2.1 to let the user type the script interactively at the keyboard.. :-) Still, it's really too early to declare the death of character mode interfaces. Yes, I'm an X hacker and I much prefer hacking on X interfaces, but an all-singing, all-dancing system written in Tk would, I believe, still be just a *bit* before its time. We'd still have all these people with perfectly reasonable systems but totally unable to get past the evil and scarey xf86config program and considerably frustrated by the exercise. For those all-too-numerous people, we need to use ncurses. And c'mon - you can still do some interesting things from ncurses, and it keeps us reasonably honest about not getting too wedded to X. Not as a first cut, but I'd like to eventually see a DOS character graphics module (as the ncurses and X11 interfaces would also be drop-in modules) written so that someone could write a custom version of the installer to run entirely under DOS. Why not? You've got full access to the BIOS there, and if you're trying to set up some sort of UMSDOS style FreeBSD installation (something we've always wanted to be able to do) why not do it right under DOS? And please don't say "DOS graphics" - I'd like an interface that responds to keystrokes in the user's lifetime.. :) > Tk. Not because it's the best, or the easiest, or anything other than that > it's _common_. On top of it, a set of form components and a form manager > in whatever language wins (your Forth 'setup', Jordan?), that eats form > specifications and generates appropriate form layouts : Oh dear, are we back to the Tk vs Ctk wars then? :-) Jordan From owner-freebsd-ports Thu Nov 23 05:48:45 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA08290 for ports-outgoing; Thu, 23 Nov 1995 05:48:45 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA08285 for ; Thu, 23 Nov 1995 05:48:42 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA28938 for ports@freebsd.org; Thu, 23 Nov 1995 13:47:44 GMT From: Michael Smith Message-Id: <199511231347.NAA28938@genesis.atrad.adelaide.edu.au> Subject: New port -ALT To: ports@freebsd.org Date: Thu, 23 Nov 1995 13:47:43 +0000 () MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1039 Sender: owner-ports@freebsd.org Precedence: bulk >From the description : "ALT is a tool for cataloging FTP sites, and searching the resulting catalog using a web browser. It is particularly suited to situations where a group of systems with extensive archives are connected to the rest of the Internet by an overloaded link." If this looks like it's interesting at all, please pick it up and drop it into the tree. It's _very_ small, and really rather useful. ftp://spam.frisbee.net.au/ALT Satoshi - I based the port layout on the bwbasic port I did a while back. Unfortunately I never got around to picking up the version you nitpicked, but I _think_ I ironed out the wrinkles this time around 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-ports Thu Nov 23 07:17:22 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA12410 for ports-outgoing; Thu, 23 Nov 1995 07:17:22 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA12403 for ; Thu, 23 Nov 1995 07:17:15 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA29078; Thu, 23 Nov 1995 15:16:12 GMT From: Michael Smith Message-Id: <199511231516.PAA29078@genesis.atrad.adelaide.edu.au> Subject: Re: Proposal 3: Non-executable file in *_DEPEND To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 23 Nov 1995 15:16:12 +0000 () Cc: msmith@atrad.adelaide.edu.au, asami@cs.berkeley.edu, ports@FreeBSD.ORG In-Reply-To: <19246.817134446@time.cdrom.com> from "Jordan K. Hubbard" at Nov 23, 95 05:47:26 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10763 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard stands accused of saying: Argh. Someone upstream just started doing something 8( > To be honest, I've been thinking about this since long before 2.1 was > even planned. This stuff is pretty old! :) Indeed; installers are like that, they grow on you. OK Mr. Application-management-person, here's your chance to beat a few people into your development team 8) > handling. I could go on. The number of special case hacks and > kludges that were added after the initial plist syntax was defined is > living proof, IMNSHO, that the original specification syntax was > flawed. I think what we're seeing here is reductionism at work. The problems posed by installation of a number of packages are so diverse that a single tool aiming to cover them all will expand to resemble a programming language regardless. Your suggested solution - giving in and starting with a language isn't invalid, it's just that it (_may_) make the general case messier. > > tar -xf --fast-read --to-stdout tarball | (cd $prefix; tar -xzf -) > > I think it's simply time to go the DEC route, where you have multiple > files comprising a package. Probably one or more foo.tgz files and a > foo.inf file for each package. Yeah, it's messier and it knocks the > paradigm of "one file per package" for a loop, but it make things a > LOT easier across all the various media I'll need to support - think > everything from floppies to FTP. The ability to _work_ with multiple files is desirable, yes. The _necessity_ for multiple files is IMHO _not_. ncftp -c |tail -c +10000 | tar xf- --fast-read +INSTALL Will DTRT for an FTP install (yes, it is rude to drop the connection. Go tell that to Netscape). Yah, it imposes a hard limit of 10K on the +INSTALL file, it's the concept that's important 8) You can pull the same trick for floppies (messier if the package contains multiple tarballs, but that's close to inevitable, and could alternatively be handled by the multiple-file support). > 5) Deal with User Preferences Behavioural constraints? The less behaviour, the fewer constraints 8) Or are we talking about package-specific user preferences? > 6) Deal with *other* packages Aigh! This is an N-complete problem - every package would have to know about every other package that it might conflict with, or which might conflict with it. I think not. Certainly, some rudimentary wolf-goat-lettuce detection would be useful, but otherwise this looks like a lot of work 8( > 7) Possibly interact with the user Agree. Most user interction will be application setup, so we write application setup programs for all those lazy software authors 8) > 8) Possibly interact with higher level installation tools. This is 7) again 8) (or at least we have to _hope_ the user is a higher-level tool 8) > 9) Be able to install system distributions Short of the horific temp-space consumption of the current technique, and the fact that sysinstall becomes a special case of 5) and 7), that's pretty straightforward. > 10) Be able to install packages by a very *wide* variety of means. Indeed. I'd like to think that we can add web and email package retrieval to ftp and local media as are currently supported 8) > It's a more complex problem that *just* what pkg_install provides. > pkg_install is actually insufficient for the task in many respects and > I wouldn't model the next generation tool after it. I guess I'm at least partly at a loss as to what you're getting at, as the current state of the art in installation tools is pretty primitive the world over. > I agree that a port install should still mimic a package install, > however that's a different area of the problem. I'm just looking at > merging packages and distributions right now. A port would just be a package in a different sort of wrapper. > dropped) and render it inoperable. There are ways of merging two tcl > applications (picking unique filenames, rebuilding index files, etc) I still suspect that this will require a lot of work to carefully synchronise all possible conflicting items, and possibly give rise to a whole new crop of gremlins. Then again, I could be wrong 8) > > > 2. A very simple 3D filesystem library. > > > > Neat. Lots of work, but possibly worth the effort. > > Well, think more than packages - think "system upgrades" and I think > you'll see why the chronological store becomes a lot more important. I'm thinking "I want my disk space for my data. If I want backups, I'll make them myself, on tape." I'm thinking that this would be a Nice Toy from the admin-weenie point of view, but the overheads would be horrific. Imagine someone tracking -stable, -current, ports and the distfiles. Naturally, sup would support the 3dfs (if it were implemented properly); imagine how much space would be consumed. Imagine the storage required to do a rollback of a major base system upgrade... Yes, I understand that you could limit the heep level - but to where? You'd have to keep at _least_ the most recent 3 versions of something. Don't get me wrong - I think the idea, and it's fundamental basis, are quite valid, but I think that implmentation would be problematic, to say the least. > > I can see us fielding a lot of questions from Lusers who have installed > > seventeen copies of emacs and filled up their "attic" filesystem though, > > and making the database smart enough to deal with damage caused by "2D" > > users/tools might be more work than the implementation itself. > > To be honest, I was thinking of doing a terrible thing (assuming I can > get away with it): I was going to hack tar and cpio to recognise 3D > file systems and let you specify "tag" information and such so that > the extraction follows the 3DFS API. E.g.: > > tar -xvzf foo.tar --3dfstag MYREL_2_1 -C /my3dfs How does this address the problem? > Could be made to DTRT. Other damage with 2D tools, well, I think we > could at the very least have an options for: > > 1. Checking tree sanity, and if a checksum fails or a delta > is found missing, report it and optionally try and fetch it > from a known-good source. You could use this to 'reconstruct' a broken installation. Then again, the same information could be held in a +LIST file in the current database format. > Both of these features would be really cool anyway and would deal with > the long-standing problem of knowing whether that /usr/src you're > looking at is *really* a good one, or if someone (maybe even sup) has > spammed it. ls -lR >foo; diff ./ls-lR.yesterday foo 8) Isn't this doing things the hard way though - should we be looking to a journalled filesystem instead? (presuming my understanding of JFS is correct...) > Still, it's really too early to declare the death of character mode > interfaces. Yes, I'm an X hacker and I much prefer hacking on X > interfaces, but an all-singing, all-dancing system written in Tk > would, I believe, still be just a *bit* before its time. We'd still > have all these people with perfectly reasonable systems but totally > unable to get past the evil and scarey xf86config program and > considerably frustrated by the exercise. For those all-too-numerous > people, we need to use ncurses. A custom-cut X server with support for nothing but VGA mono and Herc mono would have no need for configuration. You'd only have one colour model to support too 8) > And c'mon - you can still do some interesting things from ncurses, and > it keeps us reasonably honest about not getting too wedded to X. Not I'd as soon not be wedded to anything, but X exists. Its ability to talk to remote servers would also be nice in the headless case. > drop-in modules) written so that someone could write a custom version > of the installer to run entirely under DOS. Why not? You've got full > access to the BIOS there, and if you're trying to set up some sort of > UMSDOS style FreeBSD installation (something we've always wanted to be > able to do) why not do it right under DOS? I guess by that time we'll be able to license Terry's W95 UFS driver to run the filesystems off... 8) > > Tk. Not because it's the best, or the easiest, or anything other than that > > it's _common_. On top of it, a set of form components and a form manager > > in whatever language wins (your Forth 'setup', Jordan?), that eats form > > specifications and generates appropriate form layouts : > > Oh dear, are we back to the Tk vs Ctk wars then? :-) Yecch. What a hopeless paragraph that was. Sorry; what I wasn't quite seeing at the time was : the installation should be driven off a _very_ high-level script, run by a mid-level interpreter, talking to one of a number of backends. I was still thinking X, hence Tk. Something like : MENU "mainmenu" "Main Installation Menu" { ENTRY "Help!" "hotkey=H" { call "help" } ENTRY "Disk Setup" "hotkey=D" { call "diskmenu" } ENTRY "Install from...$install_source" "hotkey=I,require=diskok" { call "sourcemenu" } ENTRY "Select distributions" "hotkey=S,require=sourceok" { call "selmenu" } ENTRY "Perform Installation" "hotkey=P,require=selok" { call "install" } ENTRY "Cancel Installation" "hotkey=C,Esc" { call "canceleverything" } } MESSAGE "help" { TEXT "Sorry, no help here, sucker!" } FUNCTION "canceleverything" { ASK reponse "Cancel installation and reboot?" "Yes,[NO]" IF ($response == "Yes") { call "reboot" } } And so forth (sic). The idea being that the mid-level interpreter should handle the flow of execution, and produce the form spec to be managed by the interface-specifi driver. The menu above, on initial entry, might generate a spec like : Menu Title="Main Installation Menu" Entry="Help",Hotkey="H",Return=0 Entry="Disk Setup",Hotkey="D",Return=1 Entry="Install from...Nowhere",Disabled Entry="Select distributions",Disabled Entry="Perform Installation",Disabled Entry="Cancel Installation",Hotkey="C",Return=5 Footer="Press F1 for help",Hotkey="F1",return=6 (however it is stored...) This sort of spec could easily be parsed to produce a menu, form, whatever on a wide variety of displays, completely independant of the controlling logic. Before you ask - yes, I'm interested in working on this. Anything for a real project, instead of running around coming up with half-baked ideas on my own 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-ports Thu Nov 23 12:05:07 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA26294 for ports-outgoing; Thu, 23 Nov 1995 12:05:07 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA26289 for ; Thu, 23 Nov 1995 12:05:03 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA25007; Thu, 23 Nov 1995 12:04:39 -0800 To: Michael Smith cc: asami@cs.berkeley.edu, ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND In-reply-to: Your message of "Thu, 23 Nov 1995 15:16:12 GMT." <199511231516.PAA29078@genesis.atrad.adelaide.edu.au> Date: Thu, 23 Nov 1995 12:04:39 -0800 Message-ID: <25005.817157079@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-ports@FreeBSD.ORG Precedence: bulk > The ability to _work_ with multiple files is desirable, yes. The > _necessity_ for multiple files is IMHO _not_. > > ncftp -c |tail -c +10000 | tar xf- --fast-read +INSTALL Oh ick, I'd sooner cut my own nuts off than do something like this! :-) I appreciate that you're trying to limit the scope of development to reasonable bounds, but let's not let expediency lead us down more dark and limited paths - we've DONE that already! :-) > Behavioural constraints? The less behaviour, the fewer constraints 8) > Or are we talking about package-specific user preferences? The latter. > > > 6) Deal with *other* packages > > Aigh! This is an N-complete problem - every package would have to know > about every other package that it might conflict with, or which might > conflict with it. I think not. Certainly, some rudimentary No, this is doable. This is also not optional. This MUST work or you cannot trust the package collection to work. > I'm thinking "I want my disk space for my data. If I want backups, > I'll make them myself, on tape." I'm thinking that this would be a Nice > Toy from the admin-weenie point of view, but the overheads would be > horrific. Not necessarily. For one, who says you need 3 copies? If one is all you can afford, the 3DFS code can be smart enough to essentially become a one-level deep history mechanism. You don't lose anything you don't already lose now. For another thing, I think you're still thinking from the perspective of "one disk charlie" - disk prices are plummeting, and if we don't think just a little bit from the "a gig will be really cheap soon" perspective then we're unnecessarily hamstringing ourselves for the future. There are ways to make this work in space-starved situations, and in fact you can even turn it to your advantage. Consider a "delta" type of "compress" - you could apply a change to the tree that essentially did no more than compress a section. Roll back the pointer one step later and you uncompress it. Since every file in the tree can go through a "gate" in becoming visible (or disappearing to save space), you have a lot of flexibility. I'm trying pretty hard to make life easier for the detached developer, since we're trying so hard to recruit them these days! :-) > Imagine someone tracking -stable, -current, ports and the distfiles. > Naturally, sup would support the 3dfs (if it were implemented properly); > imagine how much space would be consumed. Now be realistic here, if they're wanting to do all of that then it's a reasonable assumption that they can afford the disk space. I certainly can, and everyone I know doing development can. If you can't then you've the pretty simple choice of *not tracking* all these items or getting with the program and buying a bigger friggin' disk! :-) Also, see above about compaction deltas and other clever tricks. If you're just working on one section of the tree at a time, I can engineer 3DFS to *save* you space, guaranteed! > You could use this to 'reconstruct' a broken installation. Then again, > the same information could be held in a +LIST file in the current > database format. No it couldn't - no MD5 checksums! > Isn't this doing things the hard way though - should we be looking to > a journalled filesystem instead? (presuming my understanding of JFS is > correct...) No, it doesn't do what we want. > > > Still, it's really too early to declare the death of character mode > > interfaces. Yes, I'm an X hacker and I much prefer hacking on X > > interfaces, but an all-singing, all-dancing system written in Tk > > would, I believe, still be just a *bit* before its time. We'd still > > have all these people with perfectly reasonable systems but totally > > unable to get past the evil and scarey xf86config program and > > considerably frustrated by the exercise. For those all-too-numerous > > people, we need to use ncurses. > > A custom-cut X server with support for nothing but VGA mono and Herc mono > would have no need for configuration. You'd only have one colour > model to support too 8) Ha ha, you're assuming that you can even get this server to work on all cards/mice/monitor situations. Trust me, you can't. The assumption that we can get even 90% of our user base straight into X from a standing start is a deeply flawed one. Trust me, I've tried and I've also listened to the technical support calls. > Before you ask - yes, I'm interested in working on this. Anything for a > real project, instead of running around coming up with half-baked ideas on > my own 8) Hmmmmm. Would you care to share the details of your design? Why not simply use TCL as the "mid-level" language spec and just not use Tk directly? The last thing we need in this life is Yet Another Specification Syntax. That was always my gripe with Ctk/Tk - I don't feel that Tk is sufficiently low-level enough to make a good emulation target. There are nicer ways of being able to say "I want a button here and I want a label there" without ever assuming an underlying concept of "button" or "label" that's less than completely generic. At another level, I'm a little tired of doing the binding at even that low level. I'd like to be able to say "get me a value for this variable" or "call me if anything representing me on the screen gets frobbed" (whatever that might be). In other words, I'd like to completely decouple of front and back ends of the app. Maybe I should just run off and do all of this and then come back with a fait accompi.. :-) Jordan From owner-freebsd-ports Thu Nov 23 14:36:05 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02312 for ports-outgoing; Thu, 23 Nov 1995 14:36:05 -0800 Received: from ncc-1701-d.starfleet.gov (ix-sb1-22.ix.netcom.com [204.32.201.54]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA02271 ; Thu, 23 Nov 1995 14:35:53 -0800 Received: (from d_burr@localhost) by ncc-1701-d.starfleet.gov (8.6.11/8.6.9) id OAA02644; Thu, 23 Nov 1995 14:38:35 -0800 Date: Thu, 23 Nov 1995 14:38:34 -0800 (PST) From: Donald Burr X-Sender: d_burr@ncc-1701-d To: FreeBSD Ports cc: FreeBSD Questions Subject: Good port of WorkMan for FreeBSD? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk Where can I find a 'good' port of WorkMan for FreeBSD 2.x? I finally tracked down the sources to workman, and was able to compile something that *almost* works, but the only problem is the EJECT button doesn't work, which is kinda frustrating. Is there a "good" port of Workman for FreeBSD 2.x out there? If so, where can I find it? And out of curiosity, why isn't it in the Ports collection? IMHO I find it to be a far superior CD player to xcd or xcdplayer, which are in the ports. Donald Burr [d_burr@ix.netcom.com], PO Box 91212, Santa Barbara CA 93190-1212 TEL (805)564-1871 // FAX 564-2315 // WWW http://www.geopages.com/WallStreet/2072 PGP Public Key available by request (send e-mail) or Public Key Servers. ** Uphold your right to privacy - Use PGP. ** From owner-freebsd-ports Thu Nov 23 21:36:19 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA21662 for ports-outgoing; Thu, 23 Nov 1995 21:36:19 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA21628 for ; Thu, 23 Nov 1995 21:36:06 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id BAA00135; Fri, 24 Nov 1995 01:45:57 GMT From: Michael Smith Message-Id: <199511240145.BAA00135@genesis.atrad.adelaide.edu.au> Subject: Re: Proposal 3: Non-executable file in *_DEPEND To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 24 Nov 1995 01:45:56 +0000 () Cc: msmith@atrad.adelaide.edu.au, asami@cs.berkeley.edu, ports@FreeBSD.ORG In-Reply-To: <25005.817157079@time.cdrom.com> from "Jordan K. Hubbard" at Nov 23, 95 12:04:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7268 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard stands accused of saying: > > ncftp -c |tail -c +10000 | tar xf- --fast-read +INSTALL > > Oh ick, I'd sooner cut my own nuts off than do something like this! :-) *laugh* - but you get what I mean though? Or should I have said "for FTP, just grab enough of the file to pull out the install script, which should be first in the wrapper" ? > > Behavioural constraints? The less behaviour, the fewer constraints 8) > > Or are we talking about package-specific user preferences? > > The latter. Agree. If we want to do that, we need a programming language. I still think that that's as much something that the original software authors have skimped on as anything, but if we want to integrate things, we do have to do the work. > > > 6) Deal with *other* packages > > > > Aigh! This is an N-complete problem - every package would have to know > > No, this is doable. This is also not optional. This MUST work or you > cannot trust the package collection to work. Well, you're the guy with the experience; I just think it's a helluva job 8) > For another thing, I think you're still thinking from the perspective > of "one disk charlie" - disk prices are plummeting, and if we don't > think just a little bit from the "a gig will be really cheap soon" > perspective then we're unnecessarily hamstringing ourselves for the As long as the tools can work _effectively_ when disk space is constrained, there's no problem. If we place our reliance (and I'm not saying that this method _would_) on a space-dependant scheme, the One Truism of Disk Space (*) will make us Real Unpopular. (*) Data always expand to occupy all available space. > I'm trying pretty hard to make life easier for the detached developer, > since we're trying so hard to recruit them these days! :-) I appreciate this. I'm not trying to detract from your vision, just commenting on the bits that I can comprehend 8) > > You could use this to 'reconstruct' a broken installation. Then again, > > the same information could be held in a +LIST file in the current > > database format. > > No it couldn't - no MD5 checksums! Who says a +LIST file wouldn't have checksums, if they'd help the process? > > A custom-cut X server with support for nothing but VGA mono and Herc mono > > would have no need for configuration. You'd only have one colour > > model to support too 8) > > Ha ha, you're assuming that you can even get this server to work on > all cards/mice/monitor situations. Trust me, you can't. No, not "all". But a large proportion, yes. I consider mice to be an extremely optional extra. Based on the same assumptions that (ecch) Windows makes, I would say that we could safely assume that the vast majority of platforms could be cajoled into offering a 640x400 monochrome visual. You can do a lot with that. > The assumption that we can get even 90% of our user base straight into > X from a standing start is a deeply flawed one. Trust me, I've tried > and I've also listened to the technical support calls. The problem with the failures is not in the failure, but in _detecting_ it and switching to a fallback 8( This is the safety net that makes _trying_ for the graphical interface worth the effort. > > Before you ask - yes, I'm interested in working on this. Anything for a > > real project, instead of running around coming up with half-baked ideas on > > my own 8) > > Hmmmmm. Would you care to share the details of your design? You've seen them all 8) If you mean "would I care to spend a lot more time working it out in detail", perhaps to the extent of a prototypical definition for the forms-layer and script-layer interfaces, sure. I'd like to be reasonably sure that I'm not running off at a tangent, though. > Why not > simply use TCL as the "mid-level" language spec and just not use Tk > directly? The last thing we need in this life is Yet Another > Specification Syntax. Um. TCL would be _good_ from the point of view of commonality, and you could extend the interpreter with appropriate primitives (I see a "disklabel" primitive, for example 8). I'm not sure whether it would be up to snuff in terms of data structure though. TCL has always been weak like that 8( > That was always my gripe with Ctk/Tk - I don't feel that Tk is > sufficiently low-level enough to make a good emulation target. There > are nicer ways of being able to say "I want a button here and I want a > label there" without ever assuming an underlying concept of "button" > or "label" that's less than completely generic. On the contrary, I think Tk is _too_ low-level. (Although perhaps we are confusing high and low here 8) Who wants, or really needs, to go that low? I'm thinking more that we want to classify the information we want (from forms, menus etc) into a limited set of types (really, there are only a few), and leave the window dressing related to extracting the information from the user to the interface-specific forms interpreter. A set of fields, like the interface configuration screen for example, would be a dialog under X, a fullscreen form on an ncurses-supported terminal, or a series of prompts/are you happy with this? questions on a glass tty interface. >From the point of view of the script controlling the installation, there's no difference. When the forms interpreter finishes running the form, it returns a set of values. End of story. > At another level, I'm a little tired of doing the binding at even that > low level. I'd like to be able to say "get me a value for this > variable" or "call me if anything representing me on the screen gets > frobbed" (whatever that might be). In other words, I'd like to > completely decouple of front and back ends of the app. Still too low-level, and too GUI-oriented. Think data, not presentation 8) Remember that something like an installation is basically a linear process. You ask a lot of questions, swap a lot of disks, and exit. The questions can usually be grouped into related sets, and there are obviously several paths the process can take, but it's essentially a gather-then-process thing. > Maybe I should just run off and do all of this and then come back > with a fait accompi.. :-) Maybe you should look to managing the project (and obviously participating), rather than trying to be Atlas? I'm not trying to peg you down (heaven forbid!), but sysinstall has always been a last-minute hide-in-the-corner thing (remember your ramblings about "setup" after 2.0.5? 8) that's had the rest of us sitting 'round twiddling our thumbs feeling sorry for you. I recognise that remote developer help can be slow to respond, and that can be maddeningly frustrating at the best of times. Just now, there's no great pressure on for something to be finished though, so isn't now perhaps a good time to get something rolling? > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-ports Fri Nov 24 00:49:24 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA05979 for ports-outgoing; Fri, 24 Nov 1995 00:49:24 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA05750 ; Fri, 24 Nov 1995 00:44:49 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA02615; Fri, 24 Nov 1995 09:43:04 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA23246; Fri, 24 Nov 1995 09:43:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA00133; Fri, 24 Nov 1995 09:29:30 +0100 From: J Wunsch Message-Id: <199511240829.JAA00133@uriah.heep.sax.de> Subject: Re: Good port of WorkMan for FreeBSD? To: d_burr@ix.netcom.com (Donald Burr) Date: Fri, 24 Nov 1995 09:29:30 +0100 (MET) Cc: freebsd-ports@freebsd.org, freebsd-questions@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Donald Burr" at Nov 23, 95 02:38:34 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 528 Sender: owner-ports@freebsd.org Precedence: bulk As Donald Burr wrote: > > Where can I find a 'good' port of WorkMan for FreeBSD 2.x? I finally > tracked down the sources to workman, and was able to compile something > that *almost* works, but the only problem is the EJECT button doesn't > work, which is kinda frustrating. I think the program needs to unlock the CD drive before ejecting. See cdcontrol(8). -- 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-ports Fri Nov 24 01:06:34 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA06556 for ports-outgoing; Fri, 24 Nov 1995 01:06:34 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA06549 for ; Fri, 24 Nov 1995 01:06:29 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id BAA01142; Fri, 24 Nov 1995 01:05:16 -0800 To: Michael Smith cc: asami@cs.berkeley.edu, ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND In-reply-to: Your message of "Fri, 24 Nov 1995 01:45:56 GMT." <199511240145.BAA00135@genesis.atrad.adelaide.edu.au> Date: Fri, 24 Nov 1995 01:05:15 -0800 Message-ID: <1140.817203915@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-ports@FreeBSD.ORG Precedence: bulk > *laugh* - but you get what I mean though? Or should I have said > "for FTP, just grab enough of the file to pull out the install script, > which should be first in the wrapper" ? My real problem with that approach is that it has these icky hard-coded constraints in there. Magic constants always get me into trouble, and assuming that the installation data will always be 10K or less just strikes me as bad. I'd much rather go to two files than accept such a hack solution, that's for sure. Make me a better offer.. :-) I should also take this opportunity to respond to some of the issues Michael raises concerning group development and how I should "manage" this effort rather than taking it all on myself (an entirely reasonable suggestion, but see below). I'm willing to consider leading a group effort, and would certainly look favorably on a scenario where a group was actually producing a much better installation framework than could formerly be produced by a single person, but I have some reservations.. For one, I would need to feel really confident in the "team" that was put together - confident that each resource within it was going to see it through and not just wander off in the middle or get jerked away suddenly. Those sorts of occurances make you just want to throw up your hands and give up on the entire concept of group development, and I've experienced such occurances in the past. If a group formed here which started looking like a truly credible R&D team, it would have a big effect on my outlook. For two, be it well understood that I'm not actually all that wild about packaging or release engineering issues. Frankly, I find this kind of coding *really boring* and the only times I seem to manage to actually write any are when: a) I've managed to figure out a neat way of solving the problem that is in itself enough motivation to do it. b) My back is against the wall and I realize that FreeBSD isn't going to have whatever feature's at stake at all unless I hack something out. So while I'd be happy to sort of direct traffic at the top, the actual technical piece I chop off is probably going to be whatever piece I happen to think is cool. If my back's to the wall I'm more likely to just beat a feature into sysinstall or pkg_install these days, so that motivation is out. :-) For three, even though I don't much care for this kind of stuff as a technical challenge, I do care very much about it from the presentation side. That's the only reason I got into this mess in the first place, in fact. I couldn't stand to see FreeBSD's first steps be a shell script and then a login prompt.. :-) This means that I'm likely to be very very opinionated about any system that evolves here. I have a very definite picture in my mind about how I want the system to ultimately look, and I daresay that it's probably not even that far from yours (though it could take us weeks just to find the right language for communicating that fact to one another! :-) This is one respect in which it's much easier for me to work alone - I don't have to spend as much time trying to explain what I've got in mind as I do actually implementing it! :-( Those are just my reservations, and I don't think they're necessarily insurrmountable, but we should discuss these things. I can say that I've made a few decisions in the last couple days' worth of contemplation. The general extension language for this whole thing will be tcl 7.5. I've looked at forth and I've looked at scheme and I've looked at my own stuff and I've even looked at PERL and only TCL seems to strike the right balance between the space it eats and the power it provides. It's also got a rich toolchest for bolting in other things (can you imagine how useful a TCL-aware installer with ``expect'' functionality compiled in would be? You could use the stand-alone floppy as a serial line analyser.. :-) and we can go graphical with Tk in the immediate term while we evolve a strategy for being pan-platform. Heck, maybe I'll just eat my words and see if we can't construct Tk interfaces that are simple enough to be displayed with Ctk.. :) [only those who remember my "Ctk sucks! No! No!" postings will really find this suggestion funny :)] It would be a very expedient solution with a fairly high return, and even if Ctk turns out to be too badly broken to use, well, then Michael gets his wish and we start making getting into X a higher priority - at least we know that Tk works well. The other big advantage to TCL is that I know it pretty well, I know how to extend it and I've figured out how to deal with C-side abstract types pretty well using various types of hash table manipulation. We could do at lot with it, and make all of the basic primitives in sysinstall tcl callable. > Based on the same assumptions that (ecch) Windows makes, I would say that we > could safely assume that the vast majority of platforms could be cajoled > into offering a 640x400 monochrome visual. You can do a lot with that. OK, I'll set to you then a challenge: Can you write a setup program for X that probes for mouse type (this is easy to do - there are standard interrogation sequences that the XFree86 people know and can tell you), presents a table of monitors and graphics cards, tests the server and gets the user to feedback on whether or not they saw whatever test pattern was put up, returning them to the setup program until they do. xf86config is just too horrible to contemplate, and looking at Xsetup from the X Inside distribution (see the demo in the commerce distribution) gives a much clearer picture of what we'd like to see. The X Inside people *do* have a 99% success rate, and what's more we even have their server! :-) The demo version will let you launch, I believe, 4 clients. That's a WM, the setup utility, an xterm and a clock.. :-) However, I'm a little loath to lean on a demo server when it only gets the user sort of installed and then leaves them without X again since the config work they did isn't actually applicable to XFree86. We need an xf86config replacement! After you did such a good job with userconfig, I'd say that xf86config will be a piece of cake! :-) > From the point of view of the script controlling the installation, there's > no difference. When the forms interpreter finishes running the form, it > returns a set of values. End of story. Ah, the forms interface perspective. I guess you're right about this, though I'd like some real-time callback ability on the individual subcomponents this time, not the static libdialog crud which never let me say "if these two are on, turn that one OFF!" for callback checks. If we can meet in the middle here, I think taking the forms approach is the right basic way to go. Just don't make it so high level that my forms become "dumb" like the libdialog objects. Jordan From owner-freebsd-ports Fri Nov 24 14:46:30 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28563 for ports-outgoing; Fri, 24 Nov 1995 14:46:30 -0800 Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28535 ; Fri, 24 Nov 1995 14:46:20 -0800 Received: (from mark@localhost) by linus.demon.co.uk (8.7.1/8.7.1) id WAA02058; Fri, 24 Nov 1995 22:46:50 GMT Date: Fri, 24 Nov 1995 22:46:50 GMT From: Mark Valentine Message-Id: <199511242246.WAA02058@linus.demon.co.uk> In-Reply-To: Donald Burr's message of Nov 23, 2:38pm X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Donald Burr , FreeBSD Ports Subject: Re: Good port of WorkMan for FreeBSD? Cc: FreeBSD Questions Sender: owner-ports@freebsd.org Precedence: bulk > Where can I find a 'good' port of WorkMan for FreeBSD 2.x? I haven't done a "port", but 1.4beta3 works pretty well for me after I unconditionalised most of the code within #ifdef __NetBSD__ in plat_freebsd.c... Mark. -- "Tigers will do ANYTHING for a tuna fish sandwich." "We're kind of stupid that way." *munch* *munch* From owner-freebsd-ports Fri Nov 24 16:06:23 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05968 for ports-outgoing; Fri, 24 Nov 1995 16:06:23 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (ns045.munich.netsurf.de [194.64.166.45]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05954 for ; Fri, 24 Nov 1995 16:06:06 -0800 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id QAA13452; Thu, 23 Nov 1995 16:31:22 +0100 Message-Id: <199511231531.QAA13452@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami) cc: ports@freebsd.org Subject: Re: Proposal 4: new category "www" Reply-To: "Julian H. Stacey" X-mailer: EXMH version 1.6.4 10/10/95 In-reply-to: Your message of "Wed, 22 Nov 1995 04:09:09 PST." <199511221209.EAA03464@silvia.HIP.Berkeley.EDU> Date: Thu, 23 Nov 1995 16:31:21 +0100 From: "Julian H. Stacey" Sender: owner-ports@freebsd.org Precedence: bulk > I prefer "www" over "web" I prefer "web" over "www" :-) Julian Julian H. Stacey EMAIL: jhs@freebsd.org WEB: http://www.freebsd.org/~jhs/ From owner-freebsd-ports Sat Nov 25 06:38:51 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01439 for ports-outgoing; Sat, 25 Nov 1995 06:38:51 -0800 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01417 ; Sat, 25 Nov 1995 06:38:23 -0800 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id PAA04112; Sat, 25 Nov 1995 15:37:55 +0100 Message-Id: <199511251437.PAA04112@gilberto.physik.rwth-aachen.de> Subject: Re: Proposal 4: new category "www" To: jhs@freebsd.org Date: Sat, 25 Nov 1995 15:37:55 +0100 (MET) Cc: asami@cs.berkeley.edu, ports@freebsd.org In-Reply-To: <199511231531.QAA13452@vector.eikon.e-technik.tu-muenchen.de> from "Julian H. Stacey" at Nov 23, 95 04:31:21 pm From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 323 Sender: owner-ports@freebsd.org Precedence: bulk > > > > I prefer "www" over "web" > I prefer "web" over "www" :-) I don't like to name it web since there is already Knuth's web (TeX). So I prefer www. > > Julian > > Julian H. Stacey EMAIL: jhs@freebsd.org WEB: http://www.freebsd.org/~jhs/ > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-ports Sat Nov 25 09:34:51 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA08704 for ports-outgoing; Sat, 25 Nov 1995 09:34:51 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA08697 for ; Sat, 25 Nov 1995 09:34:48 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA12677 for ; Sat, 25 Nov 1995 09:28:12 -0800 Prev-Resent: Sat, 25 Nov 1995 09:28:11 -0800 Prev-Resent: "ports@freebsd.org " Received: from freefall.freebsd.org (freefall.cdrom.com [192.216.222.4]) by time.cdrom.com (8.6.12/8.6.9) with ESMTP id JAA12650 for ; Sat, 25 Nov 1995 09:26:56 -0800 Received: from pain.csrv.uidaho.edu (root@pain.csrv.uidaho.edu [129.101.114.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA08641 for ; Sat, 25 Nov 1995 09:33:28 -0800 Received: from pain.csrv.uidaho.edu (fn@localhost [127.0.0.1]) by pain.csrv.uidaho.edu (8.6.12/8.6.9) with ESMTP id JAA11014 for ; Sat, 25 Nov 1995 09:33:25 -0800 Message-Id: <199511251733.JAA11014@pain.csrv.uidaho.edu> To: jkh@freebsd.org Subject: python port change. X-Web: <"http://www.hungry.com:8000/"> X-OS: 4.4BSD derivatives. X-Disclaimer: THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T X-AT&T: YOU WILL MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11003.817320797.1@pain.csrv.uidaho.edu> Date: Sat, 25 Nov 1995 09:33:19 -0800 From: Faried Nawaz Resent-To: ports@freebsd.org Resent-Date: Sat, 25 Nov 1995 09:28:11 -0800 Resent-Message-ID: <12675.817320491@time.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: owner-ports@freebsd.org Precedence: bulk hi, while compiling the python port on a -current machine, i noticed cc -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./nismodule.c In file included from ./nismodule.c:17: /usr/include/rpcsvc/ypclnt.h:66: warning: `struct dom_binding' declared inside parameter list /usr/include/rpcsvc/ypclnt.h:66: warning: its scope is only this definition or declaration, /usr/include/rpcsvc/ypclnt.h:66: warning: which is probably not what you want. i fixed it by *** Modules/nismodule.c~ Sat Nov 25 09:31:38 1995 --- Modules/nismodule.c Sat Nov 25 09:31:51 1995 *************** *** 14,24 **** #include "modsupport.h" #include "ceval.h" - #include #include #include #include #include static object *NisError; --- 14,24 ---- #include "modsupport.h" #include "ceval.h" #include #include #include #include + #include static object *NisError; this probably should be reported to the python author as well. faried. From owner-freebsd-ports Sat Nov 25 09:35:44 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA08761 for ports-outgoing; Sat, 25 Nov 1995 09:35:44 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA08755 for ; Sat, 25 Nov 1995 09:35:42 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA12688 for ; Sat, 25 Nov 1995 09:29:06 -0800 To: ports@freebsd.org Subject: Ack, ignore previous forward! Date: Sat, 25 Nov 1995 09:29:06 -0800 Message-ID: <12686.817320546@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-ports@freebsd.org Precedence: bulk I just realized that *I'm* the maintainer for the python port! :-) Jordan From owner-freebsd-ports Sat Nov 25 16:36:09 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA29471 for ports-outgoing; Sat, 25 Nov 1995 16:36:09 -0800 Received: from ncc-1701-d.starfleet.gov (ix-sb1-03.ix.netcom.com [204.32.201.35]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA29436 ; Sat, 25 Nov 1995 16:36:01 -0800 Received: (from d_burr@localhost) by ncc-1701-d.starfleet.gov (8.6.11/8.6.9) id QAA03802; Sat, 25 Nov 1995 16:38:47 -0800 Date: Sat, 25 Nov 1995 16:38:45 -0800 (PST) From: Donald Burr X-Sender: d_burr@ncc-1701-d To: FreeBSD Questions cc: FreeBSD Ports Subject: Where is the 'props' command? (olvwm) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk OpenLook (olvwm) is supposed to come with a program called "props" that allows you to set your default properties (i.e. window and screen colours, mouse behavior, etc.) This program is not included in either the olvwm or xview-* ports or packages. Any idea where (if?) I can find this command? Or, if not available, can someone tell me how to set olvwm properties manually, in my .Xdefaults file? Please reply by email and/or to freebsd-questions. Thanks! Donald Burr [d_burr@ix.netcom.com], PO Box 91212, Santa Barbara CA 93190-1212 TEL (805)564-1871 / FAX 564-2315 / WWW http://www.geopages.com/WallStreet/2072 PGP Public Key available by request (send e-mail) or on Public Key Servers. ** Uphold your right to privacy - Use PGP. ** From owner-freebsd-ports Sat Nov 25 22:28:13 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA17462 for ports-outgoing; Sat, 25 Nov 1995 22:28:13 -0800 Received: from pinch.io.org (root@pinch.io.org [198.133.36.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA17455 for ; Sat, 25 Nov 1995 22:28:08 -0800 Received: from flinch (flinch.io.org [198.133.36.153]) by pinch.io.org (8.6.9/8.6.9) with SMTP id BAA05466 for ; Sun, 26 Nov 1995 01:28:06 -0500 Date: Sun, 26 Nov 1995 01:27:44 -0500 (EST) From: Brian Tao X-Sender: taob@flinch To: FREEBSD-PORTS-L Subject: The GIMP beta on 2.1.0-RELEASE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk For those of you who have Motif and can't wait for a statically- linked binary, check out http://www.csua.berkeley.edu/~gimp/ for an *amazing* programming effort to port a Photoshop-like tool to UNIX. I grabbed the source and with some very minor fiddling (like adding in some #includes), compiled it cleanly into a 264K binary. I'll make a statically-linked binary and contribute it back to the maintainers. For a beta (hell, even a finished app), the GIMP is very impressive. Forget xpaint, this thing'll blow you away. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't"