From owner-freebsd-ports Sun Mar 19 02:15:57 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA00590 for ports-outgoing; Sun, 19 Mar 1995 02:15:57 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA00584; Sun, 19 Mar 1995 02:15:56 -0800 Message-Id: <199503191015.CAA00584@freefall.cdrom.com> X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Vince Chan cc: Joshua Peck Macdonald , FreeBSD-ports@freefall.cdrom.com Subject: Re: /usr/ports/games/xrisk In-reply-to: Your message of "Sat, 18 Mar 95 20:12:30 GMT." Date: Sun, 19 Mar 1995 02:15:55 -0800 From: Joshua Peck Macdonald Sender: ports-owner@FreeBSD.org Precedence: bulk probably something you'll kick yourself for not noticing then... hmm might be something like a permission problem, run ldconfig to be sure. Run it with the -r option to get a list of all the libs it knows about. for example: axis.root-view # ldconfig -r | grep libX11 38:-lX11.6.0 => /usr/X11R6/lib/libX11.so.6.0 (76 -> 45) 44:-lX11.2.0 => /usr/X11R6/lib/libX11.so.2.0 (13 -> 62) shows I have the old (1.1.5.1) version of the library, as well as the current (2.0) library. -josh From owner-freebsd-ports Sun Mar 19 08:19:09 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA12264 for ports-outgoing; Sun, 19 Mar 1995 08:19:09 -0800 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA12255; Sun, 19 Mar 1995 08:19:09 -0800 Date: Sun, 19 Mar 1995 08:19:09 -0800 From: "Jordan K. Hubbard" Message-Id: <199503191619.IAA12255@freefall.cdrom.com> To: ats, ports Subject: ports-japanese sup target created. Sender: ports-owner@FreeBSD.org Precedence: bulk let me know if you have any problems. -j From owner-freebsd-ports Sun Mar 19 08:38:32 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA13230 for ports-outgoing; Sun, 19 Mar 1995 08:38:32 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA13220 for ; Sun, 19 Mar 1995 08:38:25 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id SAA14205 for ; Sun, 19 Mar 1995 18:38:09 +0200 Message-Id: <199503191638.SAA14205@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: ports@FreeBSD.org Subject: Gripe of the week (tm) :-) Date: Sun, 19 Mar 1995 18:38:09 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk Hello all Can we not reorganise the X ports a little so that they do not go into /usr/X11R6/..., but rather into /usr/local/...? It is (IMO) kinda like installing ports into /usr/bin. What say you? I'm happy to do the work for those ports that I actually use. M PS. Thanks for a _helluva_ nice OS! -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sun Mar 19 08:43:37 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA13392 for ports-outgoing; Sun, 19 Mar 1995 08:43:37 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA13384 for ; Sun, 19 Mar 1995 08:43:35 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id IAA23956; Sun, 19 Mar 1995 08:42:47 -0800 From: "Rodney W. Grimes" Message-Id: <199503191642.IAA23956@gndrsh.aac.dev.com> Subject: Re: Gripe of the week (tm) :-) To: mark@grondar.za (Mark Murray) Date: Sun, 19 Mar 1995 08:42:47 -0800 (PST) Cc: ports@FreeBSD.org In-Reply-To: <199503191638.SAA14205@grunt.grondar.za> from "Mark Murray" at Mar 19, 95 06:38:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 811 Sender: ports-owner@FreeBSD.org Precedence: bulk > > Hello all > > Can we not reorganise the X ports a little so that they do not go into > /usr/X11R6/..., but rather into /usr/local/...? It is (IMO) kinda like > installing ports into /usr/bin. > > What say you? I'm happy to do the work for those ports that I actually use. > I am in rather strong agreement with Mark on this one. It is rather painfull for those of us who follow the XFree alpha/beta/release cycle and blow away our /usr/X11R6 often to have to go back and rebuild all this stuff. Or rembering which ports install into /usr/X11R6 and overriding this with a PREFIX=/usr/local. I know I loose stuff every time I upgarde XFree86 :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-ports Sun Mar 19 08:49:54 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA13603 for ports-outgoing; Sun, 19 Mar 1995 08:49:54 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA13596 for ; Sun, 19 Mar 1995 08:49:45 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id SAA14588; Sun, 19 Mar 1995 18:49:19 +0200 Message-Id: <199503191649.SAA14588@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Sun, 19 Mar 1995 18:49:19 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > > Can we not reorganise the X ports a little so that they do not go into > > /usr/X11R6/..., but rather into /usr/local/...? It is (IMO) kinda like > > installing ports into /usr/bin. > > > > What say you? I'm happy to do the work for those ports that I actually use. > > > I am in rather strong agreement with Mark on this one. It is rather > painfull for those of us who follow the XFree alpha/beta/release cycle > and blow away our /usr/X11R6 often to have to go back and rebuild > all this stuff. Great! Thanks Rod. Patches will form part of the war :-> :-> :-> M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sun Mar 19 09:03:17 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA13712 for ports-outgoing; Sun, 19 Mar 1995 09:03:17 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA13704; Sun, 19 Mar 1995 09:03:15 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: "Rodney W. Grimes" cc: mark@grondar.za (Mark Murray), ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) In-reply-to: Your message of "Sun, 19 Mar 95 08:42:47 PST." <199503191642.IAA23956@gndrsh.aac.dev.com> Date: Sun, 19 Mar 1995 09:03:15 -0800 Message-ID: <13703.795632595@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > > Can we not reorganise the X ports a little so that they do not go into > > /usr/X11R6/..., but rather into /usr/local/...? It is (IMO) kinda like > > installing ports into /usr/bin. Let me explain why I went this route in the first place: Application Defaults It's unfortunate that the way things are set up in XFree86 by default now don't really allow you to install Joe Application in such a way that it will work for all users out-of-the-box without sometimes touching /usr/X11R6. You need to install stuff into /usr/X11R6/lib just to get it found by the Xt libraries. I wish there was some analog in /usr/local that we could get searched for all subsequent releases of XFree86, but it's not that way now so I figured "oh well!" and thought we'd just settle for treating all the X11 stuff as a blob. Jordan From owner-freebsd-ports Sun Mar 19 09:14:54 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA13792 for ports-outgoing; Sun, 19 Mar 1995 09:14:54 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA13785; Sun, 19 Mar 1995 09:14:37 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id TAA16121; Sun, 19 Mar 1995 19:14:22 +0200 Message-Id: <199503191714.TAA16121@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: "Rodney W. Grimes" , mark@grondar.za (Mark Murray), ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Sun, 19 Mar 1995 19:14:22 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > It's unfortunate that the way things are set up in XFree86 by default > now don't really allow you to install Joe Application in such a way > that it will work for all users out-of-the-box without sometimes > touching /usr/X11R6. You need to install stuff into /usr/X11R6/lib > just to get it found by the Xt libraries. I wish there was some analog > in /usr/local that we could get searched for all subsequent releases of > XFree86, but it's not that way now so I figured "oh well!" and thought > we'd just settle for treating all the X11 stuff as a blob. OK, I have got the O'Reilly books on X Admin (volume 8 for R5 and the extra book for R6 both with CD's :-) ), so I'll go and research this angle. Xt being a problem hadn't occurred to me, but just bunging the binaries into /usr/X11R6 still feels too much like a hurried kluge to me rather than a fix. Any pointers you can give me about Xt will be most welcome (Right now, I haven't even looked at one single man page, so I have NO idea what I'm in for) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sun Mar 19 11:27:29 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA17720 for ports-outgoing; Sun, 19 Mar 1995 11:27:29 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA17693 for ; Sun, 19 Mar 1995 11:27:04 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id VAA19854; Sun, 19 Mar 1995 21:26:25 +0200 Message-Id: <199503191926.VAA19854@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Sun, 19 Mar 1995 21:26:25 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > I am in rather strong agreement with Mark on this one. It is rather > painfull for those of us who follow the XFree alpha/beta/release cycle > and blow away our /usr/X11R6 often to have to go back and rebuild > all this stuff. > > Or rembering which ports install into /usr/X11R6 and overriding this > with a PREFIX=/usr/local. I know I loose stuff every time I upgarde > XFree86 :-(. I am confused about how this works. (The PREFIX thingy.) I've grepped around /usr/X11R6/Lib/X11 and some of the X-ports makefiles, and I am badly confused now. (Too much work also!!). There is no mention of PREFIX in any of the {M}{Im}akefiles of the following ports: xv, xearth, ghostview, xdvi. There is also no mention of PREFIX in /usr/X11R6/lib/X11/*. Has this ever worked, is is it something else I can bang on? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sun Mar 19 11:56:25 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19736 for ports-outgoing; Sun, 19 Mar 1995 11:56:25 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA19730 for ; Sun, 19 Mar 1995 11:56:22 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id LAA24467; Sun, 19 Mar 1995 11:55:32 -0800 From: "Rodney W. Grimes" Message-Id: <199503191955.LAA24467@gndrsh.aac.dev.com> Subject: Re: Gripe of the week (tm) :-) To: mark@grondar.za (Mark Murray) Date: Sun, 19 Mar 1995 11:55:32 -0800 (PST) Cc: ports@FreeBSD.org In-Reply-To: <199503191926.VAA19854@grunt.grondar.za> from "Mark Murray" at Mar 19, 95 09:26:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1038 Sender: ports-owner@FreeBSD.org Precedence: bulk > > > I am in rather strong agreement with Mark on this one. It is rather > > painfull for those of us who follow the XFree alpha/beta/release cycle > > and blow away our /usr/X11R6 often to have to go back and rebuild > > all this stuff. > > > > Or rembering which ports install into /usr/X11R6 and overriding this > > with a PREFIX=/usr/local. I know I loose stuff every time I upgarde > > XFree86 :-(. > > I am confused about how this works. (The PREFIX thingy.) I've grepped > around /usr/X11R6/Lib/X11 and some of the X-ports makefiles, and I am > badly confused now. (Too much work also!!). > > There is no mention of PREFIX in any of the {M}{Im}akefiles of the > following ports: xv, xearth, ghostview, xdvi. There is also no mention > of PREFIX in /usr/X11R6/lib/X11/*. Has this ever worked, is is it > something else I can bang on? Look at /usr/share/mk/bsd.prot.mk. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-ports Sun Mar 19 12:32:29 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA22644 for ports-outgoing; Sun, 19 Mar 1995 12:32:29 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA22635 for ; Sun, 19 Mar 1995 12:32:21 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id WAA23136; Sun, 19 Mar 1995 22:31:45 +0200 Message-Id: <199503192031.WAA23136@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Sun, 19 Mar 1995 22:31:44 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > > I am confused about how this works. (The PREFIX thingy.) I've grepped > > around /usr/X11R6/Lib/X11 and some of the X-ports makefiles, and I am > > badly confused now. (Too much work also!!). > > > > There is no mention of PREFIX in any of the {M}{Im}akefiles of the > > following ports: xv, xearth, ghostview, xdvi. There is also no mention > > of PREFIX in /usr/X11R6/lib/X11/*. Has this ever worked, is is it > > something else I can bang on? > > Look at /usr/share/mk/bsd.prot.mk. First place I looked. Point is although these PREFIX's are created, no {Im}{M}akefile uses them. find /usr/X11R6/lib/X11 -name \* -exec grep -l PREFIX {} \; comes up blank, so does grepping the port itself. Has anybody actually got a working one? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sun Mar 19 13:30:43 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA29485 for ports-outgoing; Sun, 19 Mar 1995 13:30:43 -0800 Received: from violet.berkeley.edu (violet.Berkeley.EDU [128.32.155.22]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA29471 for ; Sun, 19 Mar 1995 13:30:38 -0800 Received: by violet.berkeley.edu (8.6.10/1.33r) id NAA23782; Sun, 19 Mar 1995 13:30:34 -0800 Date: Sun, 19 Mar 1995 13:30:34 -0800 From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Message-Id: <199503192130.NAA23782@violet.berkeley.edu> To: ports@FreeBSD.org Sender: ports-owner@FreeBSD.org Precedence: bulk Path: agate!howland.reston.ans.net!newsserver.jvnc.net!news.caren.net!news.join.ad.jp!wnoc-tyo-news!wnoc-sfc-news!fxmxgw!kspgwy!iwagw!jun From: jun@fox.fax.iwa.fujixerox.co.jp (Junichi Kurokawa) Newsgroups: comp.windows.x.i386unix,comp.unix.bsd.freebsd.misc Subject: corrupt xview-clients? lib? Followup-To: comp.windows.x.i386unix Date: 19 Mar 1995 14:22:22 GMT Organization: Fuji Xerox Co., Ltd., Akasaka, Tokyo. Lines: 12 Distribution: world Message-ID: NNTP-Posting-Host: fox.fax.iwa.fujixerox.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Xref: agate comp.windows.x.i386unix:18223 comp.unix.bsd.freebsd.misc:199 Xperts, Has anyone run xview-clients from 2.0-RELEASE/packages/xview-config.tgz? I think they're mess. None of them ran! They all SEVG'd. I also tried to compile olwm(1) from the source. No luck. Same SEGV. Is the package broken from the beginning? -- Junichi Kurokawa Enterprise Networking Development Division Fuji Xerox Co., Ltd. From owner-freebsd-ports Sun Mar 19 13:47:53 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA04539 for ports-outgoing; Sun, 19 Mar 1995 13:47:53 -0800 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA04499 for ; Sun, 19 Mar 1995 13:47:46 -0800 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA16842; Sun, 19 Mar 95 22:46:43 +0100 Date: Sun, 19 Mar 95 22:46:43 +0100 From: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Message-Id: <9503192146.AA16842@cabri.obs-besancon.fr> To: mark@grondar.za Cc: rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org In-Reply-To: <199503192031.WAA23136@grunt.grondar.za> (message from Mark Murray on Sun, 19 Mar 1995 22:31:44 +0200) Subject: Re: Gripe of the week (tm) :-) X-Mailer: Emacs Sender: ports-owner@FreeBSD.org Precedence: bulk >>>>> "Mark" == Mark Murray writes: >> > I am confused about how this works. (The PREFIX thingy.) I've grepped >> > around /usr/X11R6/Lib/X11 and some of the X-ports makefiles, and I am >> > badly confused now. (Too much work also!!). >> > >> > There is no mention of PREFIX in any of the {M}{Im}akefiles of the >> > following ports: xv, xearth, ghostview, xdvi. There is also no mention >> > of PREFIX in /usr/X11R6/lib/X11/*. Has this ever worked, is is it >> > something else I can bang on? >> >> Look at /usr/share/mk/bsd.prot.mk. > First place I looked. Point is although these PREFIX's are created, no > {Im}{M}akefile uses them. > find /usr/X11R6/lib/X11 -name \* -exec grep -l PREFIX {} \; comes up blank, > so does grepping the port itself. > Has anybody actually got a working one? In the simplest case this can be set in the Makefile with eg. MAKE_FLAGS= BINDIR=${PREFIX}/bin MANDIR=${PREFIX}/man/man1 \ XAPPLOADDIR=${PREFIX}/lib/X11/app-defaults -f (taken from xloadimage) In the case of xdvi, try `grep PREFIX Makefile' :-) > M Jean-Marc. > -- > Mark Murray > 46 Harvey Rd, Claremont, Cape Town 7700, South Africa > +27 21 61-3768 GMT+0200 ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Jean-Marc Zucconi | jmz@cabri.obs-besancon.fr Observatoire de Besancon | F 25010 Besancon cedex | PGP Key: finger jmz@cabri.obs-besancon.fr ========================================================================= From owner-freebsd-ports Sun Mar 19 18:55:23 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA09932 for ports-outgoing; Sun, 19 Mar 1995 18:55:23 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA09918 for ; Sun, 19 Mar 1995 18:55:20 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id SAA01769; Sun, 19 Mar 1995 18:54:00 -0800 Date: Sun, 19 Mar 1995 18:54:00 -0800 Message-Id: <199503200254.SAA01769@silvia.HIP.Berkeley.EDU> To: mark@grondar.za CC: rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org In-reply-to: <199503192031.WAA23136@grunt.grondar.za> (message from Mark Murray on Sun, 19 Mar 1995 22:31:44 +0200) Subject: Re: Gripe of the week (tm) :-) From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * > Look at /usr/share/mk/bsd.prot.mk. ^^or :) * First place I looked. Point is although these PREFIX's are created, no * {Im}{M}akefile uses them. Um, did you read the comments at the top then? * find /usr/X11R6/lib/X11 -name \* -exec grep -l PREFIX {} \; comes up blank, * so does grepping the port itself. Well, unless the port in question needs some special treatment, they don't really have to refer to them directly, since the targets imported from bsd.port.mk will use them. Go into emacs, open /usr/share/mk/bsd.port.mk and do C-s prefix. That's how I learned all this stuff. :) Satoshi From owner-freebsd-ports Sun Mar 19 19:25:16 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA12460 for ports-outgoing; Sun, 19 Mar 1995 19:25:16 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA12444; Sun, 19 Mar 1995 19:25:11 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id TAA01854; Sun, 19 Mar 1995 19:25:04 -0800 Date: Sun, 19 Mar 1995 19:25:04 -0800 Message-Id: <199503200325.TAA01854@silvia.HIP.Berkeley.EDU> To: jkh@freefall.cdrom.com CC: ats@freefall.cdrom.com, ports@freefall.cdrom.com In-reply-to: <199503191619.IAA12255@freefall.cdrom.com> (jkh@freefall.cdrom.com) Subject: Re: ports-japanese sup target created. From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * let me know if you have any problems. I'm sure we won't. :) By the way, I noticed that mirror sites (I checked ftp.iij.ad.jp and ftp.neosoft.com) haven't picked up the new directory. (And at least ftp.iij.ad.jp are getting files newer than ports/japanese from ftp.freebsd.org.) Is there something we need to do to tell the mirror sites about it? (I don't think so, but just wondering). Satoshi From owner-freebsd-ports Sun Mar 19 19:38:33 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA14658 for ports-outgoing; Sun, 19 Mar 1995 19:38:33 -0800 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA14642 for ports; Sun, 19 Mar 1995 19:38:30 -0800 Date: Sun, 19 Mar 1995 19:38:30 -0800 From: "Jordan K. Hubbard" Message-Id: <199503200338.TAA14642@freefall.cdrom.com> To: ports Subject: japanese and mirror sites Sender: ports-owner@FreeBSD.org Precedence: bulk ports/japanese wasn't being dragged over onto wcarchive, and thus not onto the mirror sites. This has been fixed. Jordan From owner-freebsd-ports Sun Mar 19 21:23:44 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01814 for ports-outgoing; Sun, 19 Mar 1995 21:23:44 -0800 Received: from balboa.eng.uci.edu (balboa.eng.uci.edu [128.200.61.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA01806 for ; Sun, 19 Mar 1995 21:23:43 -0800 Received: from newport.ece.uci.edu by balboa.eng.uci.edu with SMTP id AA23537 (5.65c/IDA-1.4.4 for freebsd-ports@freebsd.org); Sun, 19 Mar 1995 21:23:39 -0800 Received: from localhost by newport.ece.uci.edu (5.x/SMI-SVR4) id AA07989; Sun, 19 Mar 1995 21:23:38 -0800 Message-Id: <9503200523.AA07989@newport.ece.uci.edu> To: nate@sneezy.sri.com (Nate Williams) Cc: Paul Traina , CVS-commiters@freefall.cdrom.com, cvs-gnu@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-Reply-To: Your message of "Sun, 19 Mar 1995 18:36:42 MST." <199503200136.SAA04263@trout.sri.MT.net> Date: Sun, 19 Mar 1995 21:23:38 -0800 From: Steven Wallace Sender: ports-owner@FreeBSD.org Precedence: bulk Why were /usr/local/lib and /usr/X11/lib removed from the standard search path? Tell me WHY a program should not rely on on a "non-standard" path for brining in libraries. You say it is "non-standard", but most BSD machines use /usr/local and /usr/X11R6. What is the matter with defining this as the default search path, and then if a user wants to use /opt then they can change that if they want to? This means programs written for any previous FreeBSD version will not be able to recompile without modification. Most of the ports will now have to be updated to reflect this change. Are you willing to make all the necessary fixes to make ports work with your change? Come to think of it, this causes a big ports dillema because now a port that relies on an installed library will have to assume it is installed in a specific directory and use an explicit -L/?. Unfortunately, a user may have it installed in a different directory which will make the port fail. This is avoided by having the standard search path. Steven From owner-freebsd-ports Sun Mar 19 21:42:40 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02086 for ports-outgoing; Sun, 19 Mar 1995 21:42:40 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA02074; Sun, 19 Mar 1995 21:42:32 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id WAA06018; Sun, 19 Mar 1995 22:46:32 -0700 Date: Sun, 19 Mar 1995 22:46:32 -0700 Message-Id: <199503200546.WAA06018@trout.sri.MT.net> To: Steven Wallace Cc: Paul Traina , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-Reply-To: <9503200523.AA07989@newport.ece.uci.edu> References: <199503200136.SAA04263@trout.sri.MT.net> <9503200523.AA07989@newport.ece.uci.edu> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: ports-owner@FreeBSD.org Precedence: bulk > Why were /usr/local/lib and /usr/X11/lib removed from the standard > search path? Tell me WHY a program should not rely on on a "non-standard" > path for brining in libraries. You say it is "non-standard", but > most BSD machines use /usr/local and /usr/X11R6. Wow now, that's a statement and a half. 'Most' BSD machine probably don't have any libraries in /usr/local/lib, and ALOT of machine don't have X installed on them. Why should we make it the linker search those paths by default instead of them being specified if they don't exist? Secondly, one of the more difficult things that happens is code becomes very FreeBSD-centric, since the writer will not go out of their way to do the right things for other OS's. Try and build most of the software written specificall for Linux and you'll know what I mean. It relies on non-standard behavior of Linux, and will only work on other OS's with heavy-duty Makefile and config file hacking. > What is the matter > with defining this as the default search path, and then if a user wants > to use /opt then they can change that if they want to? Because it's non-standard. > This means programs written for any previous FreeBSD version will not > be able to recompile without modification. They are broken then. I would rather not continue this non-standard behavior here and now, so it doesn't continue on. > Most of the ports will > now have to be updated to reflect this change. Are you willing to > make all the necessary fixes to make ports work with your change? Andreas is doing that now. > Come to think of it, this causes a big ports dillema because now a > port that relies on an installed library will have to assume it is > installed in a specific directory and use an explicit -L/?. Yep. This is the way it's supposed to be done. If we are relying on a different port, then we already know where that library is installed, correct? > Unfortunately, a user may have it installed in a different directory > which will make the port fail. This is avoided by having the standard > search path. If they've installed it somewhere other than the default, then they are facing the same problem now as they would have before. It all goes down to do we want to make people 'Do The Right Thing' and have them add those extra 15 chars to the Makefile so that the code is portable across many different OS's, or make it FreeBSD specific. Most of the programs that this affects are X binaries, and *most* X binaries are built with 'xmkmf' which adds the extra -L$(XROOT) call to the linker. This is how is supposed to be done so the program can compile on many platforms without regard to where the X11 software is installed. When FreeBSD runs on other platforms, the X11 software *may* not be installed in /usr/X11R6, so do we start kludging up the source tree with what is essentially a local configuration issue. Doing the right thing now will save us time in the long run. We know where our pre-built binaries are installed, so we know (as Andreas has already done) where the files are located if the user uses them. Note, the default search path for run-time linking is still correct. The shared libraries will be found where they are installed, so it's a non issue once the program is installed. Finally, for *most* folks they install the pre-built binaries. They couldn't care less *how* a binary was built, just as long as it works. Nate From owner-freebsd-ports Sun Mar 19 21:48:49 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02337 for ports-outgoing; Sun, 19 Mar 1995 21:48:49 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA02331; Sun, 19 Mar 1995 21:48:46 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.11/8.6.9) with SMTP id VAA02959; Sun, 19 Mar 1995 21:48:09 -0800 Message-Id: <199503200548.VAA02959@precipice.Shockwave.COM> To: nate@sneezy.sri.com (Nate Williams) cc: Steven Wallace , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-reply-to: Your message of "Sun, 19 Mar 1995 22:46:32 MST." <199503200546.WAA06018@trout.sri.MT.net> Date: Sun, 19 Mar 1995 21:48:08 -0800 From: Paul Traina Sender: ports-owner@FreeBSD.org Precedence: bulk From: nate@sneezy.sri.com (Nate Williams) Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c > Why were /usr/local/lib and /usr/X11/lib removed from the standard > search path? Tell me WHY a program should not rely on on a "non-standard" > path for brining in libraries. You say it is "non-standard", but > most BSD machines use /usr/local and /usr/X11R6. Wow now, that's a statement and a half. 'Most' BSD machine probably don't have any libraries in /usr/local/lib, and ALOT of machine don't have X installed on them. Why should we make it the linker search those paths by default instead of them being specified if they don't exist? I would disagree with you. Every real -development- machine that I have ever seen has a working /usr/local{/lib}. Secondly, one of the more difficult things that happens is code becomes very FreeBSD-centric, since the writer will not go out of their way to do the right things for other OS's. Try and build most of the software written specificall for Linux and you'll know what I mean. It relies on non-standard behavior of Linux, and will only work on other OS's with heavy-duty Makefile and config file hacking. Excuse me, but /usr/local/lib is a GCC standard. This change breaks the way gcc users expect things to operate. You are thinking like the person who owns the OS, as opposed to thinking of your customers. Lots of folks like to override system libraries that they use for development by putting code in /usr/local/lib (e.g. a working libresolv.a on a sun). > This means programs written for any previous FreeBSD version will not > be able to recompile without modification. They are broken then. I would rather not continue this non-standard behavior here and now, so it doesn't continue on. Again, it's a gcc standard behavior that you are breaking just for FreeBSD. > Most of the ports will > now have to be updated to reflect this change. Are you willing to > make all the necessary fixes to make ports work with your change? Andreas is doing that now. And what about the code that hasn't been submitted for ports? Are you going to login to everyone's FreeBSD machine and fix their makefiles for them? You're fixing something that's not broken. From owner-freebsd-ports Sun Mar 19 22:01:26 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03127 for ports-outgoing; Sun, 19 Mar 1995 22:01:26 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03086 for ; Sun, 19 Mar 1995 22:01:15 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id IAA24947; Mon, 20 Mar 1995 08:00:34 +0200 Message-Id: <199503200600.IAA24947@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) cc: rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 08:00:34 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > In the simplest case this can be set in the Makefile with eg. > MAKE_FLAGS= BINDIR=${PREFIX}/bin MANDIR=${PREFIX}/man/man1 \ > XAPPLOADDIR=${PREFIX}/lib/X11/app-defaults -f > (taken from xloadimage) AHA! _This_ is the sort of thing I was looking for... > In the case of xdvi, try `grep PREFIX Makefile' :-) Hmmm.. must have missed this one :-( Thanks! -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sun Mar 19 22:03:17 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03298 for ports-outgoing; Sun, 19 Mar 1995 22:03:17 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03283; Sun, 19 Mar 1995 22:03:09 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id XAA06094; Sun, 19 Mar 1995 23:07:06 -0700 Date: Sun, 19 Mar 1995 23:07:06 -0700 Message-Id: <199503200607.XAA06094@trout.sri.MT.net> To: Paul Traina Cc: nate@sneezy.sri.com (Nate Williams), Steven Wallace , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-Reply-To: <199503200548.VAA02959@precipice.Shockwave.COM> References: <199503200546.WAA06018@trout.sri.MT.net> <199503200548.VAA02959@precipice.Shockwave.COM> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: ports-owner@FreeBSD.org Precedence: bulk Paul Traina writes: > Wow now, that's a statement and a half. 'Most' BSD machine probably > don't have any libraries in /usr/local/lib, and ALOT of machine don't > have X installed on them. Why should we make it the linker search those > paths by default instead of them being specified if they don't exist? > > I would disagree with you. Every real -development- machine that I have ever > seen has a working /usr/local{/lib}. Hmm, that's interesting. I've got a Sun box at work, and although I've got lots of libraries I *still* have to specifically add -L/usr/local/lib to them. > Secondly, one of the more difficult things that happens is code becomes > very FreeBSD-centric, since the writer will not go out of their way to > do the right things for other OS's. Try and build most of the software > written specificall for Linux and you'll know what I mean. It relies on > non-standard behavior of Linux, and will only work on other OS's with > heavy-duty Makefile and config file hacking. > > Excuse me, but /usr/local/lib is a GCC standard. This change breaks the > way gcc users expect things to operate. Scuse me. We aren't using gcc as a supplemental compiler. It's the *only* compiler on the system and as such everything it uses is installed in /usr. This means it's includes files live in /usr/include, it's libraries live in /usr/lib, and all of it's binaries live in /usr/bin and /usr/libexec. They don't live in /usr/local, UNLESS you decide to install a different version of gcc than the system default version. If you want to install and use gcc1.4, it will install itself and look for it's binaries wherever you want it to. > You are thinking like the person > who owns the OS, as opposed to thinking of your customers. Lots of folks > like to override system libraries that they use for development by putting > code in /usr/local/lib (e.g. a working libresolv.a on a sun). And those folks have to add a specific -L/usr/local/lib on their boxes for it to work. Either that, or they add it to /usr/local/lib/gcc_2_6.3/sparc-sunos4_1_3_U1/{bin|lib}, which is used because it's a non-standard part of the OS. > > This means programs written for any previous FreeBSD version will not > > be able to recompile without modification. > > They are broken then. I would rather not continue this non-standard > behavior here and now, so it doesn't continue on. > > Again, it's a gcc standard behavior that you are breaking just for FreeBSD. No I'm not. GCC is *NOT* an add-on part of the system. It doesn't have to avoid trying to mess with the standard compiler. That is the reason that gcc looks in /usr/local. As a matter of fact, if you install gcc in /usr/gnu it will only look there, and NOT look in /usr/local. It looks where it's installed, and in FreeBSD it's /usr And, I don't know why we are talking about GCC here. I modified the linker/loader to not look there. What compiler we are using is irrelevant to the issue. > > Most of the ports will > > now have to be updated to reflect this change. Are you willing to > > make all the necessary fixes to make ports work with your change? > > Andreas is doing that now. > > And what about the code that hasn't been submitted for ports? Are you > going to login to everyone's FreeBSD machine and fix their makefiles > for them? Uhh, yeah. Everyone send me their root password and machine names so I can go fix the sources on your boxes. Really, that's all I am going to do, nothing more. :-) If the code relies on the linker looking in non-standard directories for it's libraries then it needs to be fixed. > You're fixing something that's not broken. Adding those libraries to the search path is a FreeBSD-specific addition that was made to bootstrap some things early on. However, these changes shouldn't have continued on in the system. The search path is now set to what most system linker/loaders do. (Some of them add all of their other libraries, but since we don't have separated out libraries trees for sys5 libraries and BSD libraries it's a non-issue for us) Nate From owner-freebsd-ports Sun Mar 19 22:09:25 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03800 for ports-outgoing; Sun, 19 Mar 1995 22:09:25 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03790 for ; Sun, 19 Mar 1995 22:09:19 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id IAA24996; Mon, 20 Mar 1995 08:06:04 +0200 Message-Id: <199503200606.IAA24996@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: mark@grondar.za, rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 08:06:04 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > Well, unless the port in question needs some special treatment, they > don't really have to refer to them directly, since the targets > imported from bsd.port.mk will use them. > > Go into emacs, open /usr/share/mk/bsd.port.mk and do C-s prefix. > That's how I learned all this stuff. :) Sure, I did this kind of thing too. Try this; put the line PREFIX= /usr/local into the /usr/ports/x11/xearth/Makefile, type make install and watch xearth get installed into /usr/X11R6!! There is a BIG problem here! M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sun Mar 19 22:11:13 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA04007 for ports-outgoing; Sun, 19 Mar 1995 22:11:13 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA04000; Sun, 19 Mar 1995 22:11:10 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.11/8.6.9) with SMTP id WAA03069; Sun, 19 Mar 1995 22:10:34 -0800 Message-Id: <199503200610.WAA03069@precipice.Shockwave.COM> To: nate@sneezy.sri.com (Nate Williams) cc: Steven Wallace , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-reply-to: Your message of "Sun, 19 Mar 1995 23:07:06 MST." <199503200607.XAA06094@trout.sri.MT.net> Date: Sun, 19 Mar 1995 22:10:20 -0800 From: Paul Traina Sender: ports-owner@FreeBSD.org Precedence: bulk Let me try a different tact. Would you agree that our cc should behave in the same fashion as NetBSD/386's cc and BSD/386's cc or do you think that FreeBSD should differ from *BSD? From owner-freebsd-ports Sun Mar 19 22:11:49 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA04093 for ports-outgoing; Sun, 19 Mar 1995 22:11:49 -0800 Received: from balboa.eng.uci.edu (balboa.eng.uci.edu [128.200.61.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA04087 for ; Sun, 19 Mar 1995 22:11:48 -0800 Received: from localhost.uci.edu by balboa.eng.uci.edu with SMTP id AA25167 (5.65c/IDA-1.4.4 for freebsd-ports@freebsd.org); Sun, 19 Mar 1995 22:11:38 -0800 Message-Id: <199503200611.AA25167@balboa.eng.uci.edu> To: nate@sneezy.sri.com (Nate Williams) Cc: Paul Traina , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-Reply-To: Your message of "Sun, 19 Mar 1995 22:46:32 MST." <199503200546.WAA06018@trout.sri.MT.net> Date: Sun, 19 Mar 1995 22:11:37 -0800 From: Steven Wallace Sender: ports-owner@FreeBSD.org Precedence: bulk >> Why were /usr/local/lib and /usr/X11/lib removed from the standard >> search path? Tell me WHY a program should not rely on on a "non-standard" >> path for brining in libraries. You say it is "non-standard", but >> most BSD machines use /usr/local and /usr/X11R6. > > Wow now, that's a statement and a half. 'Most' BSD machine probably > don't have any libraries in /usr/local/lib, and ALOT of machine don't > have X installed on them. Why should we make it the linker search those > paths by default instead of them being specified if they don't exist? > I should have said that is where we have our ports install: /usr/local/lib and /usr/X11R6/lib. > Secondly, one of the more difficult things that happens is code becomes > very FreeBSD-centric, since the writer will not go out of their way to > do the right things for other OS's. Try and build most of the software > written specificall for Linux and you'll know what I mean. It relies on > non-standard behavior of Linux, and will only work on other OS's with > heavy-duty Makefile and config file hacking. I agree. > >> What is the matter >> with defining this as the default search path, and then if a user wants >> to use /opt then they can change that if they want to? > > Because it's non-standard. Who sets the standard? How come for FreeBSD versions 1 and 2 this WAS the standard? > >> This means programs written for any previous FreeBSD version will not >> be able to recompile without modification. > > They are broken then. I would rather not continue this non-standard > behavior here and now, so it doesn't continue on. > Okay, fine. We can say it is 'broken' even though it worked fine before. My big question to you is did you take into consideration the ramificaions of your change before you made it? A change that affects an entire source tree is significant. I am upset that if the FreeBSD team wanted to implement this change it was not discussed and then written into the ports GUIDLINES that strict -L inclusion was to be used for all ports. Now that we are coming close to a new release this change is made late in the ballgame. Now some ports will have to be redone when they could have been done 'correctly' in the first place and saved ports people time if this library search standard was the goal of the team. So the decision is to keep this change and make the FreeBSD world 'fix' their Makefiles NOW, later, or not at all. > It all goes down to do we want to make people 'Do The Right Thing' and > have them add those extra 15 chars to the Makefile so that the code is > portable across many different OS's, or make it FreeBSD specific. > BTW, please tell me what are those extra 15 chars to make everything magically portable? If I do a -L/usr/local/lib in my Makefile and then some other platform uses /opt/lib, don't they have to change my Makefile? If search paths were used then this change would not be needed. Steven From owner-freebsd-ports Sun Mar 19 22:17:39 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA04502 for ports-outgoing; Sun, 19 Mar 1995 22:17:39 -0800 Received: from kbrown.oldcampus.yale.edu (root@kbrown.oldcampus.yale.edu [130.132.128.124]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA04496; Sun, 19 Mar 1995 22:17:38 -0800 Date: Mon, 20 Mar 1995 01:16:53 +0000 From: Vince Chan Subject: Re: /usr/ports/games/xrisk To: Joshua Peck Macdonald cc: Joshua Peck Macdonald , FreeBSD-ports@freefall.cdrom.com In-Reply-To: <199503191015.CAA00584@freefall.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk On Sun, 19 Mar 1995, Joshua Peck Macdonald wrote: > probably something you'll kick yourself for not noticing then... hmm > might be something like a permission problem, run ldconfig to be > sure. Run it with the -r option to get a list of all the libs it > knows about. for example: > > axis.root-view # ldconfig -r | grep libX11 > 38:-lX11.6.0 => /usr/X11R6/lib/libX11.so.6.0 (76 -> 45) > 44:-lX11.2.0 => /usr/X11R6/lib/libX11.so.2.0 (13 -> 62) > > shows I have the old (1.1.5.1) version of the library, as well as the > current (2.0) library. > > -josh > Just tried it but I didn't have a X11 showing up anywhere....Know what needs to be done with xrisk to make it compile? Cheers, Vince E-mail: vince@kbrown.oldcampus.yale.edu,\|/ Sys Adm - CircleStar Technologies,Inc. root@berkeley.circlestar.com,(o o) San Francisco, California USA _________________________oOO__(_)__OOo_____________________________ | There are many forms of science but only physics is the quantum | | leap of the 21st Century. | \_________________________________________________________________/ uPoy@physics.ucla.edu UCLA Physics/Electrical Engineering Los Angeles, California USA GUS Digest Adminstrator Advanced Gravis UltraSound Card - The ultimate in soundcard technology System Administrator - bigbang.HIP.Berkeley.EDU From owner-freebsd-ports Sun Mar 19 22:33:06 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA05083 for ports-outgoing; Sun, 19 Mar 1995 22:33:06 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA05076 for ; Sun, 19 Mar 1995 22:33:04 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id WAA02581; Sun, 19 Mar 1995 22:29:04 -0800 Date: Sun, 19 Mar 1995 22:29:04 -0800 Message-Id: <199503200629.WAA02581@silvia.HIP.Berkeley.EDU> To: mark@grondar.za CC: ports@FreeBSD.org In-reply-to: <199503200606.IAA24996@grunt.grondar.za> (message from Mark Murray on Mon, 20 Mar 1995 08:06:04 +0200) Subject: Re: Gripe of the week (tm) :-) From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * Try this; put the line * * PREFIX= /usr/local * * into the /usr/ports/x11/xearth/Makefile, type make install and watch xearth * get installed into /usr/X11R6!! * * There is a BIG problem here! Um, that doesn't work because your imake config files are saying otherwise! bsd.port.mk depends on imake to create the Makefile for X utilities. Go into your imake config dir and look at site.def, you should find #define ProjectRoot /usr/X11R6 Change that line to where you want to put your X tree. This was what I did when I had my X stuff in /usr/local/X11 before; but trust me, it's not a very good idea, it's much easier to simply accept the default and be compatible with the rest of the world. Satoshi From owner-freebsd-ports Sun Mar 19 22:46:15 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA05745 for ports-outgoing; Sun, 19 Mar 1995 22:46:15 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA05736 for ; Sun, 19 Mar 1995 22:46:09 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id WAA02621; Sun, 19 Mar 1995 22:45:46 -0800 Date: Sun, 19 Mar 1995 22:45:46 -0800 Message-Id: <199503200645.WAA02621@silvia.HIP.Berkeley.EDU> To: jmz@cabri.obs-besancon.fr CC: mark@grondar.za, rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org In-reply-to: <9503192146.AA16842@cabri.obs-besancon.fr> (jmz@cabri.obs-besancon.fr) Subject: Re: Gripe of the week (tm) :-) From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * In the simplest case this can be set in the Makefile with eg. * MAKE_FLAGS= BINDIR=${PREFIX}/bin MANDIR=${PREFIX}/man/man1 \ * XAPPLOADDIR=${PREFIX}/lib/X11/app-defaults -f * (taken from xloadimage) Are you sure this is what the user wants? I thought it is the Xt library that determines where to look for app-defaults stuff, so unless you built your libXt.so.* to look into someplace else, it would still try to open /usr/X11R6/lib/X11/app-defaults. No? The above looks like it will just change the directories this program will get installed into. And replying to Rod's remarks, you can't really do that unless Xt is rewritten to be able to look for more than one directory for app-defaults. Also, imake thinks that where the standard X libraries are is where you want new libraries to get installed, etc., so you also need to rewrite the imake config files if you want to keep the "standard" and "optional" X stuff in separate places. What I did in order not to have to blow out the entire X tree is as follows. I created two directories, say /usr/local/X11/dist and /usr/local/X11/new, and put the entire XFree86 distribution under the former. /usr/X11R6 is a symlink to /usr/local/X11/new, which has the standard subdirectories (bin, include, lib, man), which are populated with symlinks. The depth that the symlinks are differ depending on the subdirectory, as bin has symlinks right under it, lib has links for lib*, and then a subdirectory X11, which is all symlinks except for app-defaults, which has symlinks inside it. man of course has subdirectories man1, man3, etc., and then they have symlinks inside them. (Of course you can implement this by creating the symlink tree under /usr/X11R6, but I find it easier to have "dist" and "new" side by side when I make links by relative paths.) Anyway, ihe idea is to have "real" directories where your new X program will install stuff, so that they won't go away when you upgrade your XFree86. I simply rename dist to dist.old or something and extract the whole thing again when a new XFree86 comes out. I need to check to see if the links are up to date, but this isn't all that hard. Satoshi From owner-freebsd-ports Sun Mar 19 23:35:40 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA08353 for ports-outgoing; Sun, 19 Mar 1995 23:35:40 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA08345 for ; Sun, 19 Mar 1995 23:35:37 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id XAA26037; Sun, 19 Mar 1995 23:33:58 -0800 From: "Rodney W. Grimes" Message-Id: <199503200733.XAA26037@gndrsh.aac.dev.com> Subject: Re: Gripe of the week (tm) :-) To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Date: Sun, 19 Mar 1995 23:33:57 -0800 (PST) Cc: jmz@cabri.obs-besancon.fr, mark@grondar.za, ports@FreeBSD.org In-Reply-To: <199503200645.WAA02621@silvia.HIP.Berkeley.EDU> from "Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=" at Mar 19, 95 10:45:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1565 Sender: ports-owner@FreeBSD.org Precedence: bulk > > * In the simplest case this can be set in the Makefile with eg. > * MAKE_FLAGS= BINDIR=${PREFIX}/bin MANDIR=${PREFIX}/man/man1 \ > * XAPPLOADDIR=${PREFIX}/lib/X11/app-defaults -f > * (taken from xloadimage) > > Are you sure this is what the user wants? I thought it is the Xt > library that determines where to look for app-defaults stuff, so > unless you built your libXt.so.* to look into someplace else, it would > still try to open /usr/X11R6/lib/X11/app-defaults. No? > > The above looks like it will just change the directories this program > will get installed into. Yep, and then you have to go hack up Xt or do what I did, and copy the app-defaults into /usr/local, since I modify these anyway (and I hate to loose those changes too) that was the route I choose. > And replying to Rod's remarks, you can't really do that unless Xt is > rewritten to be able to look for more than one directory for > app-defaults. Also, imake thinks that where the standard X libraries > are is where you want new libraries to get installed, etc., so you > also need to rewrite the imake config files if you want to keep the > "standard" and "optional" X stuff in separate places. I think this is probably something we should take up with the XFree86/Xconsortium folks. It is rather painful to not have the same flexibility we do with the OS in XFree86. ... > Satoshi > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-ports Mon Mar 20 00:33:35 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA12960 for ports-outgoing; Mon, 20 Mar 1995 00:33:35 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA12951; Mon, 20 Mar 1995 00:33:32 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: nate@sneezy.sri.com (Nate Williams) cc: Steven Wallace , Paul Traina , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-reply-to: Your message of "Sun, 19 Mar 95 22:46:32 MST." <199503200546.WAA06018@trout.sri.MT.net> Date: Mon, 20 Mar 1995 00:33:32 -0800 Message-ID: <12950.795688412@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk I agree completely and utterly with Nate. Having a port just magically work because /usr/local/lib and /usr/X11R6/lib are magically tacked on by the system is one of the purest forms of evil there is; it masks your true dependencies and causes people to be unforgivably lazy in their porting habits, making "freebsd-centric" software arise to further plague those who would like their large free software collections to compile on *multiple* platforms. This was a good change, and one of the prime examples of what we need to do to actually simplify certain parts of the system if we're not to dig a big ugly hole for ourselves to later fall into. Jordan From owner-freebsd-ports Mon Mar 20 00:34:23 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13023 for ports-outgoing; Mon, 20 Mar 1995 00:34:23 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA13011 for ; Mon, 20 Mar 1995 00:34:20 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id AAA03299; Mon, 20 Mar 1995 00:33:11 -0800 Date: Mon, 20 Mar 1995 00:33:11 -0800 Message-Id: <199503200833.AAA03299@silvia.HIP.Berkeley.EDU> To: mark@grondar.za CC: ports@FreeBSD.org In-reply-to: <199503200629.WAA02581@silvia.HIP.Berkeley.EDU> (asami@cs.berkeley.edu) Subject: Re: Gripe of the week (tm) :-) From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk (following up on my previous message on this subject....) * Um, that doesn't work because your imake config files are saying * otherwise! bsd.port.mk depends on imake to create the Makefile for X * utilities. Go into your imake config dir and look at site.def, you * should find * * #define ProjectRoot /usr/X11R6 * * Change that line to where you want to put your X tree. Actually, if we really want to change this from within bsd.port.mk, it is possible. We can make it invoke imake with -DProjectRoot=${PREFIX} (or X11BASE?). The problem is that there is no way to pass this option through xmkmf, and calling imake directly might give us compatibility problems when future releases of X comes out with an xmkmf that calls imake with a different set of arguments (currently it's "imake -DUseInstalled -I/usr/X11R6/lib/X11/config" with a preceding mv to backup the Makefile). Also, I'm not convinced that this is a good idea anyway. If you want your X stuff in a different place, you *should* edit your site.def or you'll have to fix your Makefiles every time you call xmkmf by yourself and not from bsd.port.mk. Satoshi From owner-freebsd-ports Mon Mar 20 00:38:21 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13219 for ports-outgoing; Mon, 20 Mar 1995 00:38:21 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA13202; Mon, 20 Mar 1995 00:38:13 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: Paul Traina cc: nate@sneezy.sri.com (Nate Williams), Steven Wallace , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-reply-to: Your message of "Sun, 19 Mar 95 21:48:08 PST." <199503200548.VAA02959@precipice.Shockwave.COM> Date: Mon, 20 Mar 1995 00:38:12 -0800 Message-ID: <13201.795688692@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk If it's truly a gcc "feature" to link in /usr/local/lib then I would have to say, with 15 years experience in porting software across extremely disparate UN*X platforms, that this is something that gcc got entirely wrong. The only thing /usr/local/lib is guaranteed to be is utterly unreliable on any given machine (I have no control over it) and the minute you start pointing off into the void in hopes that something good will happen (and doing it behind the user's back, so it's not even immediately obvious when things go badly wrong!), you're setting yourself up for a fall. gcc was broken, Nate has fixed it. Whomever decided to point into an essentially randomly populated directory by default in gcc should be shot and skinned. It was a stupid decision. Period. Jordan From owner-freebsd-ports Mon Mar 20 00:40:38 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13399 for ports-outgoing; Mon, 20 Mar 1995 00:40:38 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA13391; Mon, 20 Mar 1995 00:40:36 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: Mark Murray cc: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=), rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) In-reply-to: Your message of "Mon, 20 Mar 95 08:06:04 +0200." <199503200606.IAA24996@grunt.grondar.za> Date: Mon, 20 Mar 1995 00:40:36 -0800 Message-ID: <13390.795688836@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > Try this; put the line > > PREFIX= /usr/local > > into the /usr/ports/x11/xearth/Makefile, type make install and watch xearth > get installed into /usr/X11R6!! You're not loooooking! Seriously, guy, this is painfully obvious with a 10 second look at bsd.port.mk. Look at it again. You'll plainly see where X11BASE overrides the PREFIX. Jordan From owner-freebsd-ports Mon Mar 20 00:49:51 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13853 for ports-outgoing; Mon, 20 Mar 1995 00:49:51 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA13847; Mon, 20 Mar 1995 00:49:48 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id AAA03383; Mon, 20 Mar 1995 00:49:40 -0800 Date: Mon, 20 Mar 1995 00:49:40 -0800 Message-Id: <199503200849.AAA03383@silvia.HIP.Berkeley.EDU> To: jkh@freefall.cdrom.com CC: mark@grondar.za, rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org In-reply-to: <13390.795688836@freefall.cdrom.com> (jkh@freefall.cdrom.com) Subject: Re: Gripe of the week (tm) :-) From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * Seriously, guy, this is painfully obvious with a 10 second look at * bsd.port.mk. Look at it again. You'll plainly see where X11BASE * overrides the PREFIX. Ha ha Jordan, gotcha here. The line you are talking about is PREFIX?= ${X11BASE} ^see? :) so it's not overriding, it's the (overridable) default! :) BTW, as I wrote in an earlier mail, it's imake config files that decide where to install the X stuff. PREFIX is usually only used in packages and stuff. (So you'll find yourself in a deep hole if you don't have them in sync!) Satoshi From owner-freebsd-ports Mon Mar 20 00:51:30 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13947 for ports-outgoing; Mon, 20 Mar 1995 00:51:30 -0800 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA13933; Mon, 20 Mar 1995 00:51:14 -0800 Received: from freebsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA16351; Mon, 20 Mar 95 09:50:13 +0100 Received: by freebsd.first.gmd.de (JAA16985); Mon, 20 Mar 1995 09:52:05 +0100 From: Andreas Schulz Message-Id: <199503200852.JAA16985@freebsd.first.gmd.de> Subject: Re: ports-japanese sup target created. To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Date: Mon, 20 Mar 1995 09:52:04 +0059 (MET) Cc: jkh@freefall.cdrom.com, ats@freefall.cdrom.com, ports@freefall.cdrom.com In-Reply-To: <199503200325.TAA01854@silvia.HIP.Berkeley.EDU> from "Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=" at Mar 19, 95 07:25:04 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 603 Sender: ports-owner@FreeBSD.org Precedence: bulk > By the way, I noticed that mirror sites (I checked ftp.iij.ad.jp and > ftp.neosoft.com) haven't picked up the new directory. (And at least > ftp.iij.ad.jp are getting files newer than ports/japanese from > ftp.freebsd.org.) > > Is there something we need to do to tell the mirror sites about it? > (I don't think so, but just wondering). They need to add a new sup line for that in their supfile. ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de ) Andreas Schulz GMD-FIRST 12489 Berlin-Adlershof Rudower Chaussee 5 Gebaeude 13.7 Tel: +49-30-6392-1856/+49-177-2134745 Germany/Europe From owner-freebsd-ports Mon Mar 20 01:17:45 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA15494 for ports-outgoing; Mon, 20 Mar 1995 01:17:45 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA15479; Mon, 20 Mar 1995 01:17:35 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: Steven Wallace cc: nate@sneezy.sri.com (Nate Williams), Paul Traina , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-reply-to: Your message of "Sun, 19 Mar 95 22:11:37 PST." <199503200611.AA25167@balboa.eng.uci.edu> Date: Mon, 20 Mar 1995 01:17:35 -0800 Message-ID: <15477.795691055@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > Who sets the standard? How come for FreeBSD versions 1 and 2 this WAS > the standard? Because we were asleep at the switch. Seriously. There are a LOT of bogons like this in our system where somebody bandaided something to make it work and it either went unnoticed or has simply never been important enough in anyone's eyes to immediately fix, but its historical precedence doesn't make it "right". In this case, it's very plain to me that if we want to make a `magic' directory in FreeBSD like /usr/local/lib, the place to do it is NOT in the compiler, it's in the appropriate makefile macros! You can still make it every bit as `default' if you really wish to, but NOT in the compiler! It's simply the wrong place, IMNSHO. Jordan From owner-freebsd-ports Mon Mar 20 02:07:05 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA18624 for ports-outgoing; Mon, 20 Mar 1995 02:07:05 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA18505; Mon, 20 Mar 1995 02:05:57 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.11/jtpda-5.0) with SMTP id LAA06046 ; Mon, 20 Mar 1995 11:05:08 +0100 Received: by blaise.ibp.fr (4.1/SMI-4.1) id AA19603; Mon, 20 Mar 95 11:04:56 +0100 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <9503201004.AA19603@blaise.ibp.fr> Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c To: nate@sneezy.sri.com Date: Mon, 20 Mar 1995 11:04:56 +0100 (MET) Cc: swallace@newport.ece.uci.edu, pst@shockwave.com, CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org In-Reply-To: <199503200546.WAA06018@trout.sri.MT.net> from "Nate Williams" at Mar 19, 95 10:46:32 pm X-Operating-System: FreeBSD 2.1.0-Development ctm#429 X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 300 Sender: ports-owner@FreeBSD.org Precedence: bulk > > Because it's non-standard. /usr/local/lib has been a gcc standard for years... I may understand the removal of /usr/X11R6 but not /usr/local/lib ! -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.1.0-Development #1: Mon Mar 6 23:55:18 MET 1995 From owner-freebsd-ports Mon Mar 20 02:12:21 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA18964 for ports-outgoing; Mon, 20 Mar 1995 02:12:21 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA18925; Mon, 20 Mar 1995 02:12:10 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id CAA25757; Mon, 20 Mar 1995 02:12:04 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id CAA13893; Mon, 20 Mar 1995 02:12:03 -0800 Message-Id: <199503201012.CAA13893@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: roberto@blaise.ibp.fr (Ollivier Robert) cc: nate@sneezy.sri.com, swallace@newport.ece.uci.edu, pst@shockwave.com, CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-reply-to: Your message of "Mon, 20 Mar 95 11:04:56 +0100." <9503201004.AA19603@blaise.ibp.fr> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 20 Mar 1995 02:11:56 -0800 Sender: ports-owner@FreeBSD.org Precedence: bulk >> Because it's non-standard. > >/usr/local/lib has been a gcc standard for years... I may understand the >removal of /usr/X11R6 but not /usr/local/lib ! The standard in this case has nothing to do with gcc. While the "system" compiler happens to be gcc, it should function as a traditional system "cc" compiler. This means that it shouldn't be off messing with "local" directories. I feel pretty strongly about this - I've been hosed by its behavior myself when it was off snooping at some junk I had in /usr/local. Should I desire to install another 'gcc' in /usr/local/*, then that one can poke around in there, but the system supplied compiler should not. -DG From owner-freebsd-ports Mon Mar 20 07:40:21 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA28746 for ports-outgoing; Mon, 20 Mar 1995 07:40:21 -0800 Received: from kryten.atinc.com (kryten.atinc.com [198.138.38.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA28739 for ; Mon, 20 Mar 1995 07:40:17 -0800 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id KAA29158; Mon, 20 Mar 1995 10:37:22 -0500 Date: Mon, 20 Mar 1995 10:37:21 -0500 (EST) From: "Jonathan M. Bresler" Subject: tk3.6.tgz To: ports@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk the tk PACKAGE does not have tk_library defined. per the 'tcl and tk' book, i defined the enviorment variable TK_LIBRARY. no joy. this is not used by the package. the error message is (by memory) Tcl_AppInit: tk_library is not defined. jmb so is it me? my garlic laden lunch? got any certs? Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-ports Mon Mar 20 10:03:17 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA01425 for ports-outgoing; Mon, 20 Mar 1995 10:03:17 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA01417; Mon, 20 Mar 1995 10:03:04 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id UAA27957; Mon, 20 Mar 1995 20:02:46 +0200 Message-Id: <199503201802.UAA27957@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=), rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 20:02:45 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > > Try this; put the line > > > > PREFIX= /usr/local > > > > into the /usr/ports/x11/xearth/Makefile, type make install and watch xearth > > get installed into /usr/X11R6!! > > You're not loooooking! > > Seriously, guy, this is painfully obvious with a 10 second look at > bsd.port.mk. Look at it again. You'll plainly see where X11BASE > overrides the PREFIX. I saw this round about the first time I brought up the subject: (Yes, it is obvious, I found it quick-quick) -----------(extracts from /usr/share/mk/bsd.port.mk)---------- X11BASE?= /usr/X11R6 .if defined(USE_IMAKE) PREFIX?= ${X11BASE} .else PREFIX?= /usr/local .endif -----------(extracts from /usr/share/mk/bsd.port.mk)---------- The point I am tring to make is THAT IT DOES NOT WORK! Like I said above, TRY IT! PLEASE look at my "PREFIX= ..." statement above... I have commented out everything in sight to do with both X11BASE and PREFIX, I have hard-coded, grepped and find(1)-ed what I could. So far nothing works. This is mainly due to a complete lack of experience in imake/xmkmf and Imakefiles (which give me brainache). The closest I have gotten to anything working is a macro (?) called ProjectBase in imake.rules or site.def (or somewhere that tries to move everything to wherevery you specify, and consequently breaks the make. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Mon Mar 20 10:21:06 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA01906 for ports-outgoing; Mon, 20 Mar 1995 10:21:06 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA01895 for ; Mon, 20 Mar 1995 10:20:40 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id UAA28034; Mon, 20 Mar 1995 20:18:56 +0200 Message-Id: <199503201818.UAA28034@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: jmz@cabri.obs-besancon.fr, rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 20:18:55 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > * In the simplest case this can be set in the Makefile with eg. > * MAKE_FLAGS= BINDIR=${PREFIX}/bin MANDIR=${PREFIX}/man/man1 \ > * XAPPLOADDIR=${PREFIX}/lib/X11/app-defaults -f > * (taken from xloadimage) > > Are you sure this is what the user wants? I thought it is the Xt > library that determines where to look for app-defaults stuff, so > unless you built your libXt.so.* to look into someplace else, it would > still try to open /usr/X11R6/lib/X11/app-defaults. No? Hmmm. This seems like a half decent first approximation. My original gripe was to get the user-generated X binaries out of /usr/X11R6, and if we have to leave a symlink in this (X11R6) tree to the .../app-defaults, it is a lot closer than not doing it at all. > The above looks like it will just change the directories this program > will get installed into. That is what I was aiming at (partially). > And replying to Rod's remarks, you can't really do that unless Xt is > rewritten to be able to look for more than one directory for > app-defaults. Also, imake thinks that where the standard X libraries > are is where you want new libraries to get installed, etc., so you > also need to rewrite the imake config files if you want to keep the > "standard" and "optional" X stuff in separate places. What is wrong with symlinking the "standard" and "local" app-defaults together? (asks an X neophyte :). Surely even if you upgrade your X through a recompile, you will want to keep your hard-worked-on defaults? > What I did in order not to have to blow out the entire X tree is as > follows. I created two directories, say /usr/local/X11/dist and > /usr/local/X11/new, and put the entire XFree86 distribution under the > former. /usr/X11R6 is a symlink to /usr/local/X11/new, which has the > standard subdirectories (bin, include, lib, man), which are populated > with symlinks. Seems to me that with not _too_ much work we could do a lot better than that...? > The depth that the symlinks are differ depending on the subdirectory, > as bin has symlinks right under it, lib has links for lib*, and then a > subdirectory X11, which is all symlinks except for app-defaults, which > has symlinks inside it. man of course has subdirectories man1, man3, > etc., and then they have symlinks inside them. Sure. It is possible to go _crazy_ and do what you like with these symlinks, but life gets awfully messy. Lets just do it _right_. > Anyway, ihe idea is to have "real" directories where your new X > program will install stuff, so that they won't go away when you > upgrade your XFree86. I simply rename dist to dist.old or something > and extract the whole thing again when a new XFree86 comes out. I > need to check to see if the links are up to date, but this isn't all > that hard. It is very manual. With a clear separation of the two trees, and a _known_ grey area (app-defaults) (which is kinda-like /etc in that it contains all your local setups, kluges, preferences etc, no?), surely life will be a lot easier? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Mon Mar 20 10:22:32 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA01934 for ports-outgoing; Mon, 20 Mar 1995 10:22:32 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA01920 for ; Mon, 20 Mar 1995 10:21:53 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id UAA28063; Mon, 20 Mar 1995 20:21:12 +0200 Message-Id: <199503201821.UAA28063@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 20:21:12 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > Um, that doesn't work because your imake config files are saying > otherwise! bsd.port.mk depends on imake to create the Makefile for X > utilities. Go into your imake config dir and look at site.def, you > should find > > #define ProjectRoot /usr/X11R6 > > Change that line to where you want to put your X tree. > > This was what I did when I had my X stuff in /usr/local/X11 before; > but trust me, it's not a very good idea, it's much easier to simply > accept the default and be compatible with the rest of the world. That puts _all_ the X stuff in whatever directory you specify. I want to separate the "pure" X from local installations. -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Mon Mar 20 10:31:08 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA02063 for ports-outgoing; Mon, 20 Mar 1995 10:31:08 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA02045 for ; Mon, 20 Mar 1995 10:30:49 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id UAA28097; Mon, 20 Mar 1995 20:29:09 +0200 Message-Id: <199503201829.UAA28097@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=), jmz@cabri.obs-besancon.fr, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 20:29:08 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > I think this is probably something we should take up with the > XFree86/Xconsortium folks. It is rather painful to not have the > same flexibility we do with the OS in XFree86. So who is going to go to the Great Chief of the X Consortium, Hat-in-hand, and crave audience? ;-) Seriously - Is this where it is rooted? I thought is seemed too hard-coded in the Imakefile system... M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Mon Mar 20 10:33:13 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA02167 for ports-outgoing; Mon, 20 Mar 1995 10:33:13 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA02136 for ; Mon, 20 Mar 1995 10:32:44 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id UAA28128; Mon, 20 Mar 1995 20:32:14 +0200 Message-Id: <199503201832.UAA28128@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 20:32:13 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > (following up on my previous message on this subject....) > > * Um, that doesn't work because your imake config files are saying > * otherwise! bsd.port.mk depends on imake to create the Makefile for X > * utilities. Go into your imake config dir and look at site.def, you > * should find > * > * #define ProjectRoot /usr/X11R6 > * > * Change that line to where you want to put your X tree. > > Actually, if we really want to change this from within bsd.port.mk, it > is possible. We can make it invoke imake with -DProjectRoot=${PREFIX} > (or X11BASE?). Naah. Doesn't work. After this the build tries to find too much in the specfied tree, and blows up. > Also, I'm not convinced that this is a good idea anyway. If you want > your X stuff in a different place, you *should* edit your site.def or > you'll have to fix your Makefiles every time you call xmkmf by > yourself and not from bsd.port.mk. Again, I want to _split_ my X stuff. "Pure" vs "local". M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Mon Mar 20 10:59:12 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA03010 for ports-outgoing; Mon, 20 Mar 1995 10:59:12 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA03001 for ; Mon, 20 Mar 1995 10:59:03 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id KAA00462; Mon, 20 Mar 1995 10:55:29 -0800 From: "Rodney W. Grimes" Message-Id: <199503201855.KAA00462@gndrsh.aac.dev.com> Subject: Re: Gripe of the week (tm) :-) To: mark@grondar.za (Mark Murray) Date: Mon, 20 Mar 1995 10:55:29 -0800 (PST) Cc: asami@cs.berkeley.edu, jmz@cabri.obs-besancon.fr, ports@FreeBSD.org In-Reply-To: <199503201829.UAA28097@grunt.grondar.za> from "Mark Murray" at Mar 20, 95 08:29:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 753 Sender: ports-owner@FreeBSD.org Precedence: bulk > > > I think this is probably something we should take up with the > > XFree86/Xconsortium folks. It is rather painful to not have the > > same flexibility we do with the OS in XFree86. > > So who is going to go to the Great Chief of the X Consortium, Hat-in-hand, > and crave audience? ;-) That's why I said XFree86, they are much easier to get a hold of and talk about this with and they are a Xconsortium member!!! > Seriously - Is this where it is rooted? I thought is seemed too hard-coded > in the Imakefile system... And just who controls the source to the Imakefile system?? :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-ports Mon Mar 20 12:01:11 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA04568 for ports-outgoing; Mon, 20 Mar 1995 12:01:11 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA04562 for ; Mon, 20 Mar 1995 12:00:58 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id VAA28927; Mon, 20 Mar 1995 21:58:43 +0200 Message-Id: <199503201958.VAA28927@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: mark@grondar.za (Mark Murray), asami@cs.berkeley.edu, jmz@cabri.obs-besancon.fr, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Mon, 20 Mar 1995 21:58:43 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > > Seriously - Is this where it is rooted? I thought is seemed too hard-coded > > in the Imakefile system... > > And just who controls the source to the Imakefile system?? :-) ^^^ Does this ----------------| Cough. Mean er, _we_ do? :-)? :-)? :-)? Or is it merely as excellent as the XFree86 folks? :-)? :-)? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Mon Mar 20 14:30:04 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA10322 for ports-outgoing; Mon, 20 Mar 1995 14:30:04 -0800 Received: from isl.cf.ac.uk (isl-gate.elsy.cf.ac.uk [131.251.22.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA10299 for ; Mon, 20 Mar 1995 14:29:56 -0800 Received: (from paul@localhost) by isl.cf.ac.uk (8.6.9/8.6.9) id WAA26437; Mon, 20 Mar 1995 22:27:59 GMT From: Paul Richards Message-Id: <199503202227.WAA26437@isl.cf.ac.uk> Subject: Re: Gripe of the week (tm) :-) To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 20 Mar 1995 22:27:59 +0000 (GMT) Cc: mark@grondar.za, ports@FreeBSD.org In-Reply-To: <199503191642.IAA23956@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Mar 19, 95 08:42:47 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1203 Sender: ports-owner@FreeBSD.org Precedence: bulk In reply to Rodney W. Grimes who said > > > > > Hello all > > > > Can we not reorganise the X ports a little so that they do not go into > > /usr/X11R6/..., but rather into /usr/local/...? It is (IMO) kinda like > > installing ports into /usr/bin. > > > > What say you? I'm happy to do the work for those ports that I actually use. > > > I am in rather strong agreement with Mark on this one. It is rather > painfull for those of us who follow the XFree alpha/beta/release cycle > and blow away our /usr/X11R6 often to have to go back and rebuild > all this stuff. > > Or rembering which ports install into /usr/X11R6 and overriding this > with a PREFIX=/usr/local. I know I loose stuff every time I upgarde > XFree86 :-(. This has been a long standing gripe of mine. The problem is that most X software expects to be able to play around in the X tree and I've seen enough cases of this to stop arguing about it. Think app-defaults if nothing else. -- Paul Richards, FreeBSD core team member. Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ From owner-freebsd-ports Mon Mar 20 16:36:11 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA16197 for ports-outgoing; Mon, 20 Mar 1995 16:36:11 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.223.46]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA16190 for ; Mon, 20 Mar 1995 16:36:09 -0800 Received: (from jkh@localhost) by time.cdrom.com (8.6.11/8.6.9) id QAA00185 for ports@freefall; Mon, 20 Mar 1995 16:36:04 -0800 Date: Mon, 20 Mar 1995 16:36:04 -0800 From: "Jordan K. Hubbard" Message-Id: <199503210036.QAA00185@time.cdrom.com> To: ports@freefall.cdrom.com Subject: I wonder if this works for us - any xtrek players out there? Sender: ports-owner@FreeBSD.org Precedence: bulk From: fwmiller@cs.umd.edu (Frank W. Miller) [1] COW Netrek client for NetBSD 1.0 /i386 Date: Mon Mar 20 08:22:15 PST 1995 Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 24 A COW client for NetBSD 1.0 / i386 is now available at the following ftp site: infant2.sphs.indiana.edu:/pub/netrek/COW/COW-bin/COW.1.02pl2.netbsd-i386.gz This is a blessed RSA binary that I know works on bigbang. I have uploaded the key but I don't know when it will be picked up by other servers. Let me know if there are any problems, ENJOY! Later, FM (aka YouDieWithMe) From owner-freebsd-ports Mon Mar 20 17:33:55 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA20252 for ports-outgoing; Mon, 20 Mar 1995 17:33:55 -0800 Received: from isl.cf.ac.uk (isl-gate.elsy.cf.ac.uk [131.251.22.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA20246 for ; Mon, 20 Mar 1995 17:33:53 -0800 Received: (from paul@localhost) by isl.cf.ac.uk (8.6.9/8.6.9) id BAA27276; Tue, 21 Mar 1995 01:33:26 GMT From: Paul Richards Message-Id: <199503210133.BAA27276@isl.cf.ac.uk> Subject: Re: Gripe of the week (tm) :-) To: mark@grondar.za (Mark Murray) Date: Tue, 21 Mar 1995 01:33:26 +0000 (GMT) Cc: rgrimes@gndrsh.aac.dev.com, asami@cs.berkeley.edu, jmz@cabri.obs-besancon.fr, ports@FreeBSD.org In-Reply-To: <199503201829.UAA28097@grunt.grondar.za> from "Mark Murray" at Mar 20, 95 08:29:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 777 Sender: ports-owner@FreeBSD.org Precedence: bulk In reply to Mark Murray who said > > > I think this is probably something we should take up with the > > XFree86/Xconsortium folks. It is rather painful to not have the > > same flexibility we do with the OS in XFree86. > > So who is going to go to the Great Chief of the X Consortium, Hat-in-hand, > and crave audience? ;-) > > Seriously - Is this where it is rooted? I thought is seemed too hard-coded > in the Imakefile system... Talk to Rich, (rich@FreeBSD.org) since he's not only on the XFree86 core team but ours too. -- Paul Richards, FreeBSD core team member. Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ From owner-freebsd-ports Mon Mar 20 18:15:10 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA21119 for ports-outgoing; Mon, 20 Mar 1995 18:15:10 -0800 Received: from Starbase.NeoSoft.COM (root@starbase.NeoSoft.COM [198.64.6.26]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA21113; Mon, 20 Mar 1995 18:15:08 -0800 Received: from metal.ops.neosoft.com (root@glenn-slip53.nmt.edu [129.138.5.153]) by Starbase.NeoSoft.COM (8.6.10/8.6.10) with ESMTP id UAA17461; Mon, 20 Mar 1995 20:14:59 -0600 X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 Received: (from smace@localhost) by metal.ops.neosoft.com (8.6.11/8.6.10) id TAA10812; Mon, 20 Mar 1995 19:14:56 -0700 From: Scott Mace Message-Id: <199503210214.TAA10812@metal.ops.neosoft.com> Subject: Re: I wonder if this works for us - any xtrek players out there? To: jkh@FreeBSD.org (Jordan K. Hubbard) Date: Mon, 20 Mar 1995 19:14:55 -0700 (MST) Cc: ports@freefall.cdrom.com In-Reply-To: <199503210036.QAA00185@time.cdrom.com> from "Jordan K. Hubbard" at Mar 20, 95 04:36:04 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 783 Sender: ports-owner@FreeBSD.org Precedence: bulk > > From: fwmiller@cs.umd.edu (Frank W. Miller) > [1] COW Netrek client for NetBSD 1.0 /i386 > Date: Mon Mar 20 08:22:15 PST 1995 > Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 > Lines: 24 > > A COW client for NetBSD 1.0 / i386 is now available at the following > ftp site: > > infant2.sphs.indiana.edu:/pub/netrek/COW/COW-bin/COW.1.02pl2.netbsd-i386.gz > > This is a blessed RSA binary that I know works on bigbang. I have > uploaded the key but I don't know when it will be picked up by other > servers. > > Let me know if there are any problems, ENJOY! > > Later, > FM > (aka YouDieWithMe) > The bsdi one does for sure... :-) The freebsd one would probably work if you happened to keep a XFree86 2.1 compatdist....(if one existed) Scott From owner-freebsd-ports Mon Mar 20 18:54:14 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA24764 for ports-outgoing; Mon, 20 Mar 1995 18:54:14 -0800 Received: from condor.oscs.montana.edu (condor.oscs.montana.edu [192.31.215.175]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA24724; Mon, 20 Mar 1995 18:54:10 -0800 Received: (from handy@localhost) by condor.oscs.montana.edu (8.6.8/8.6.6) id TAA03177; Mon, 20 Mar 1995 19:49:04 -0700 Date: Mon, 20 Mar 1995 19:49:04 -0700 From: Brian Handy Message-Id: <199503210249.TAA03177@condor.oscs.montana.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Jordan K. Hubbard" , ports@freefall.cdrom.com Subject: Re: I wonder if this works for us - any xtrek players out there? Sender: ports-owner@FreeBSD.org Precedence: bulk Hi All, I don't know about the COW client, but I compiled COW-lite to run under 1.1.5.1 some time ago -- it's got the RSA stuff and works fine. It's available at the following ftp site: esoteric.agron.iastate.edu:/pub/netrek/COW-lite/bin/cow-lite-1.20.FreeBSD.gz ...if'n I ever get around to upgrading to FBSD 2.x, I'll recompile a new cow-lite client. Happy Trails, Brian Handy handy@condor.oscs.montana.edu From owner-freebsd-ports Mon Mar 20 19:17:52 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA00727 for ports-outgoing; Mon, 20 Mar 1995 19:17:52 -0800 Received: from kryten.atinc.com (kryten.atinc.com [198.138.38.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA00689 for ; Mon, 20 Mar 1995 19:17:40 -0800 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id WAA03342; Mon, 20 Mar 1995 22:14:20 -0500 Date: Mon, 20 Mar 1995 22:14:19 -0500 (EST) From: "Jonathan M. Bresler" Subject: tk port/package To: ports@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk the problem that i reported earlier in the tk3.6 package: Tcl_AppInit failed: tk_library variable doesn't exist only occurs with the package. the port compiles with TK_LIBRARY defined as /usr/local/lib/tk and runs wish beautifully ;) just getting closer closer to XTeXshell all the time ;) jmb Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-ports Mon Mar 20 22:17:40 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA00750 for ports-outgoing; Mon, 20 Mar 1995 22:17:40 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA00744 for ; Mon, 20 Mar 1995 22:17:29 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id IAA01367; Tue, 21 Mar 1995 08:16:32 +0200 Message-Id: <199503210616.IAA01367@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: Paul Richards cc: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes), ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Tue, 21 Mar 1995 08:16:31 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > This has been a long standing gripe of mine. The problem is that most > X software expects to be able to play around in the X tree and I've seen > enough cases of this to stop arguing about it. Think app-defaults if > nothing else. I have seen enough evidence to consider app-defaults an exception. how about separating "core" and "local", and just leave app-defaults? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Mon Mar 20 22:19:31 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA00830 for ports-outgoing; Mon, 20 Mar 1995 22:19:31 -0800 Received: from isl.cf.ac.uk (isl-gate.elsy.cf.ac.uk [131.251.22.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA00823 for ; Mon, 20 Mar 1995 22:19:29 -0800 Received: (from paul@localhost) by isl.cf.ac.uk (8.6.9/8.6.9) id GAA00286; Tue, 21 Mar 1995 06:19:12 GMT From: Paul Richards Message-Id: <199503210619.GAA00286@isl.cf.ac.uk> Subject: Re: Gripe of the week (tm) :-) To: mark@grondar.za (Mark Murray) Date: Tue, 21 Mar 1995 06:19:12 +0000 (GMT) Cc: rgrimes@gndrsh.aac.dev.com, ports@FreeBSD.org In-Reply-To: <199503210616.IAA01367@grunt.grondar.za> from "Mark Murray" at Mar 21, 95 08:16:31 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 853 Sender: ports-owner@FreeBSD.org Precedence: bulk In reply to Mark Murray who said > > > This has been a long standing gripe of mine. The problem is that most > > X software expects to be able to play around in the X tree and I've seen > > enough cases of this to stop arguing about it. Think app-defaults if > > nothing else. > > I have seen enough evidence to consider app-defaults an exception. > how about separating "core" and "local", and just leave app-defaults? > If anything at all gets written to the X tree then it tends to negate the point. I think we should get in touch with the XFree86 folks and push to have the whole thing done properly. -- Paul Richards, FreeBSD core team member. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff. From owner-freebsd-ports Mon Mar 20 22:55:26 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02027 for ports-outgoing; Mon, 20 Mar 1995 22:55:26 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA02020 for ; Mon, 20 Mar 1995 22:55:20 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id WAA08178; Mon, 20 Mar 1995 22:54:04 -0800 Date: Mon, 20 Mar 1995 22:54:04 -0800 Message-Id: <199503210654.WAA08178@silvia.HIP.Berkeley.EDU> To: mark@grondar.za CC: ports@FreeBSD.org In-reply-to: <199503201818.UAA28034@grunt.grondar.za> (message from Mark Murray on Mon, 20 Mar 1995 20:18:55 +0200) Subject: Re: Gripe of the week (tm) :-) From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * Sure. It is possible to go _crazy_ and do what you like with these * symlinks, but life gets awfully messy. Lets just do it _right_. Well, I might be CRAZY (*-_-*) but I thought this, although it might be wrong, was the only way to solve the problem entirely within the X tree. I didn't like having two separate bin dirs, man dirs, etc. It will clutter up my PATH, /etc/manpath.config, /etc/weekly, among other things. * It is very manual. With a clear separation of the two trees, and a _known_ * grey area (app-defaults) (which is kinda-like /etc in that it contains all * your local setups, kluges, preferences etc, no?), surely life will be a lot * easier? Actually the whole lib/ subdirectory and much of include/ is a gray zone. (bin/ and man/ aren't that difficult to separate.) Don't forget that X programs often want to install their own libraries and/or header files, and the imake system just isn't prepared to deal with two sets of these. They think where you install = where you find libs/includes. So you either fix things with symlinks like I said, or as Rod suggested, go the imake config way. The latter is much better and is the "real" solution but it takes time and we need to cooperate with the XFree86/X Consortium people...the former is, well, dirty and "incorrect" but at least gives you the illusion of having a "standard" X tree (very important to do port works) with minimal effort during upgrades. Maintaining the symlink tree isn't all that bad, as "colorls -GR | colorless" can tell me about all the bogus symlinks. For the new files, I just run the setup script again, it will fail when the link is already there. Satoshi From owner-freebsd-ports Mon Mar 20 23:03:49 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA02729 for ports-outgoing; Mon, 20 Mar 1995 23:03:49 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA02701 for ; Mon, 20 Mar 1995 23:03:39 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id JAA02312; Tue, 21 Mar 1995 09:03:16 +0200 Message-Id: <199503210703.JAA02312@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Tue, 21 Mar 1995 09:03:16 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > So you either fix things with symlinks like I said, or as Rod > suggested, go the imake config way. The latter is much better and is > the "real" solution but it takes time and we need to cooperate with > the XFree86/X Consortium people...the former is, well, dirty and > "incorrect" but at least gives you the illusion of having a "standard" > X tree (very important to do port works) with minimal effort during > upgrades. I think this is now more _strong_ incentive to get in touch with the Xfree86/X Consortium folks. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Tue Mar 21 02:59:46 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA15267 for ports-outgoing; Tue, 21 Mar 1995 02:59:46 -0800 Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA15261 for ; Tue, 21 Mar 1995 02:59:45 -0800 Received: from tartufo.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA29887; Tue, 21 Mar 95 02:59:51 -0800 Received: by tartufo.pcs.dec.com (/\=-/\ Smail3.1.16.1 #16.39) id ; Tue, 21 Mar 95 11:58 MET Message-Id: Date: Tue, 21 Mar 95 11:58 MET From: me@tartufo.pcs.dec.com (Michael Elbel) To: mark@grondar.za Cc: ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Newsgroups: pcs.freebsd.ports References: <199503201818.UAA28034@grunt.grondar.za> Reply-To: me@FreeBSD.org Sender: ports-owner@FreeBSD.org Precedence: bulk In pcs.freebsd.ports you write: >> still try to open /usr/X11R6/lib/X11/app-defaults. No? Not necessarily >Hmmm. This seems like a half decent first approximation. My original gripe >was to get the user-generated X binaries out of /usr/X11R6, and if we have to >leave a symlink in this (X11R6) tree to the .../app-defaults, it is a >lot closer than not doing it at all. If it's just app-defaults then there are standard ways to have a search path for that. There's the environment variables XFILESEARCHPATH, XUSERFILESEARCHPATH and XAPPLRESDIR all of which can be used to find app-defaults files in 'non-standard' places (Do a 'man X' e.g.). How to set them globally is left as an exercise to the reader :-) Michael-- Michael Elbel, Digital-PCS GmbH, Muenchen, Germany - me@FreeBSD.org Fermentation fault (coors dumped) From owner-freebsd-ports Tue Mar 21 06:34:00 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA21183 for ports-outgoing; Tue, 21 Mar 1995 06:34:00 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id GAA21176; Tue, 21 Mar 1995 06:33:59 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: mark@grondar.za, ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) In-reply-to: Your message of "Mon, 20 Mar 95 22:54:04 PST." <199503210654.WAA08178@silvia.HIP.Berkeley.EDU> Date: Tue, 21 Mar 1995 06:33:58 -0800 Message-ID: <21175.795796438@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk My spin on all of this is that homegrown "solutions" to the /usr/X11R6 dependency problem are just bogus. I have no interest whatsoever in changing the current scheme of things and will resist any such initiatives for the time being. They're guaranteed to buy us little more than confusion and incompatability with the rest of the XFree86 world. If we want to work with the X Consortium folks on a longer term and farther ranging solution, then let's do that. Until then, I'd like to get on with our business if generating content! Jordan From owner-freebsd-ports Tue Mar 21 07:44:58 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA23166 for ports-outgoing; Tue, 21 Mar 1995 07:44:58 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA23143; Tue, 21 Mar 1995 07:44:37 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id RAA07393; Tue, 21 Mar 1995 17:44:16 +0200 Message-Id: <199503211544.RAA07393@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=), ports@FreeBSD.org Subject: Re: Gripe of the week (tm) :-) Date: Tue, 21 Mar 1995 17:44:16 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk I'll go with this, (reluctantly). Much more work than I anticipated. :-( > My spin on all of this is that homegrown "solutions" to the /usr/X11R6 > dependency problem are just bogus. I have no interest whatsoever in > changing the current scheme of things and will resist any such > initiatives for the time being. They're guaranteed to buy us little > more than confusion and incompatability with the rest of the XFree86 > world. > > If we want to work with the X Consortium folks on a longer term and farther > ranging solution, then let's do that. Until then, I'd like to get on with > our business if generating content! -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Tue Mar 21 11:46:48 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA00970 for ports-outgoing; Tue, 21 Mar 1995 11:46:48 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA00961; Tue, 21 Mar 1995 11:46:46 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: Chuck Robey cc: gj@FreeBSD.org, chuckr%Glue.umd.edu@inet-gw-1.pa.dec.com, ports@FreeBSD.org Subject: Re: Debugging In-reply-to: Your message of "Tue, 21 Mar 95 14:36:07 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Mar 1995 11:46:46 -0800 Message-ID: <960.795815206@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > I think that people oughta know about this....the interface that the tgdb > package provides to the gdb debugger is so graphical! And useful, > colorful, this is the most useful debugger I've seen. Anyone else > interested, I'll be glad to go over what I had to do to get it running. > I sure recommend looking at tgdb, even if you're not in the middle of a > development project, just to see a really neat example of a tcl based > application. Unlike ups, it didn't have any incompatibilities with the > existing gdb version, it just uses it, not recompiles it. Uh, well, a _port_ for this baby sure wouldn't hurt! It doesn't matter if it's shareware since we don't have to actually provide it in binary form, we can do JUST a port without an associated package. This would help many people discover the magic of tgdb that wouldn't otherwise do so (like ME, for example - I haven't the time to track down the bits and generally won't bother with something if it's not a port). Jordan From owner-freebsd-ports Tue Mar 21 12:38:00 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA02602 for ports-outgoing; Tue, 21 Mar 1995 12:38:00 -0800 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA02595 for ports; Tue, 21 Mar 1995 12:37:59 -0800 Date: Tue, 21 Mar 1995 12:37:59 -0800 From: "Jordan K. Hubbard" Message-Id: <199503212037.MAA02595@freefall.cdrom.com> To: ports Subject: truth or fiction? Sender: ports-owner@FreeBSD.org Precedence: bulk Receiving file: lynx2-3-7.tar.Z 100% 0 847831 bytes. ETA: 0:00 lynx2-3-7.tar.Z: 847831 bytes received in 201.96 seconds, 4.10 K/s. >> Checksum mismatch for lynx2-3-7.tar.Z *** Error code 1 From owner-freebsd-ports Tue Mar 21 12:57:54 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA02977 for ports-outgoing; Tue, 21 Mar 1995 12:57:54 -0800 Received: from rivers.oscs.montana.edu (rivers.oscs.montana.edu [192.31.215.70]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA02970 for ; Tue, 21 Mar 1995 12:57:53 -0800 Received: by rivers.oscs.montana.edu (5.65/DEC-Ultrix/4.3) id AA09987; Tue, 21 Mar 1995 13:57:48 -0700 Date: Tue, 21 Mar 1995 13:57:48 -0700 (MST) From: Jason Boerner To: ports@FreeBSD.org Subject: How too??? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk I read the FAQ in /usr/share/FAQ but was unable to answer the most important question. How? How do I pull ports over ftp without having to re-create (by hand) every subdirectory in the ports collection and performing an mget * for each of them? It seems to me that there should be a world mountable F.S. for me too "mount r" that I can use to run the makefiles directly off of. From owner-freebsd-ports Tue Mar 21 13:32:36 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA04113 for ports-outgoing; Tue, 21 Mar 1995 13:32:36 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA04105 for ; Tue, 21 Mar 1995 13:32:34 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id NAA02121 for ports@freebsd.org; Tue, 21 Mar 1995 13:32:29 -0800 From: Poul-Henning Kamp Message-Id: <199503212132.NAA02121@ref.tfs.com> Subject: Re: Debugging (commin to a CD near us ?) To: ports@FreeBSD.org Date: Tue, 21 Mar 1995 13:32:29 -0800 (PST) Content-Type: text Content-Length: 2542 Sender: ports-owner@FreeBSD.org Precedence: bulk Who does the port ? Forwarded message: > From owner-freebsd-hackers@freefall.cdrom.com Tue Mar 21 13:30:36 1995 > Message-Id: <199503211323.NAA02764@star-gate.com> > X-Authentication-Warning: star-gate.com: Host localhost didn't use HELO protocol > X-Mailer: exmh version 1.6alpha 2/16/95 > To: hackers@FreeBSD.org > Subject: Re: Debugging > In-reply-to: Your message of "Tue, 21 Mar 1995 14:36:07 EST." > > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Date: Tue, 21 Mar 1995 13:22:56 +0000 > From: User & > Sender: hackers-owner@FreeBSD.org > Precedence: bulk > > > Some tidbits on how I managed to build tgdb on FreeBSD. > > I found tgdb at: > wcarchive.cdrom.com:/.4/linux/sunsite/devel/debuggers/tgdb-1.1.src.tgz > > >From the INSTALL notes: > To build tgdb_wish, the Tcl/Tk interpreter for tgdb's code, the following > packages are needed: > > tcl7.3 > tk3.6 (or tk3.6pl1) > tclX7.3a (or tclX7.3b) > BLT1.3 (or newer) > TkSteal3.6c (or newer) > expect5.3 (or newer) > > ------------- > > In freebsd.cdrom.com, you will find patches for blt, tcl, tk, tclX: > wcarchive.cdrom.com:/.11/FreeBSD/FreeBSD-current/ports/x11/tk > wcarchive.cdrom.com:/.11/FreeBSD/FreeBSD-current/ports/x11/blt > wcarchive.cdrom.com:/.11/FreeBSD/FreeBSD-current/ports/lang/tcl > wcarchive.cdrom.com:/.11/FreeBSD/FreeBSD-current/ports/lang/tclX > wcarchive.cdrom.com:/.11/FreeBSD/FreeBSD-current/ports/lang/expect > > I untar all the packages to /usr/local/src: > star-gate# ls /usr/local/src > TkSteal expect-5.13 tclX7.3b > blt-1.7 tcl7.3 tk3.6 > > (don't use blt-1.7) > > Apply all the respective patches to the packages. > > Go to each sub-directories in the following order tcl7.3, tk3.6,tclX7.3b, > blt-1.7, expect-5.13 and execute: > ./configure > make > make install > > To configure TkSteal: > ./configure -with-expect -with-blt -with-tclX > make > make install > > The resulting wish is all that you now need to run tgdb :) > > When making tgdb, the make file will need to use bash and > of course gnu's make. > > > Is a cool debugger however it needs a bit more work to make it > look as good as exmh which of course I am using right now :) > > Have fun, > Amancio > > > > -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-ports Tue Mar 21 13:41:05 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA04543 for ports-outgoing; Tue, 21 Mar 1995 13:41:05 -0800 Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA04536 for ; Tue, 21 Mar 1995 13:41:00 -0800 Received: from tartufo.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA10353; Tue, 21 Mar 95 13:39:25 -0800 Received: by tartufo.pcs.dec.com (/\=-/\ Smail3.1.16.1 #16.39) id ; Tue, 21 Mar 95 22:38 MET Message-Id: Date: Tue, 21 Mar 95 22:38 MET From: me@tartufo.pcs.dec.com (Michael Elbel) To: chaos@rivers.oscs.montana.edu Cc: ports@FreeBSD.org Subject: Re: How too??? Newsgroups: pcs.freebsd.ports References: Reply-To: me@FreeBSD.org Sender: ports-owner@FreeBSD.org Precedence: bulk In pcs.freebsd.ports you write: >I read the FAQ in /usr/share/FAQ but was unable to answer the most >important question. How? How do I pull ports over ftp without having to >re-create (by hand) every subdirectory in the ports collection and >performing an mget * for each of them? Get the whole stuff (or subdirectories you're intereted in) as compressed tar file using wu-ftpd's magic: cd /pub/FreeBSD get ports.tar.gz <- where there's a directory ports >It seems to me that there should be a world mountable F.S. for me too >"mount r" that I can use to run the makefiles directly off of. Hmm, I suppose you could do this by defining WRKDIR to point somewhere writable (as an environment variable), but then *every* port would share it. Michael -- Michael Elbel, Digital-PCS GmbH, Muenchen, Germany - me@FreeBSD.org Fermentation fault (coors dumped) From owner-freebsd-ports Tue Mar 21 15:53:44 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA10919 for ports-outgoing; Tue, 21 Mar 1995 15:53:44 -0800 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA10912 for ports; Tue, 21 Mar 1995 15:53:43 -0800 Date: Tue, 21 Mar 1995 15:53:43 -0800 From: "Jordan K. Hubbard" Message-Id: <199503212353.PAA10912@freefall.cdrom.com> To: ports Subject: Where are all the database weenies when you need them? :-) Sender: ports-owner@FreeBSD.org Precedence: bulk ports/db: msql That's pretty thin, guys! What happened to ingres? postgres? outgres? throughgres? At least _one_ other database sure wouldn't hurt! Any Minerva fans out there? Jordan From owner-freebsd-ports Tue Mar 21 19:26:34 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA17437 for ports-outgoing; Tue, 21 Mar 1995 19:26:34 -0800 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA17423 for ports; Tue, 21 Mar 1995 19:26:33 -0800 Date: Tue, 21 Mar 1995 19:26:33 -0800 From: "Jordan K. Hubbard" Message-Id: <199503220326.TAA17423@freefall.cdrom.com> To: ports Subject: /wcarchive/archive/pub/FreeBSD/packages/tgdb1_1.tgz Sender: ports-owner@FreeBSD.org Precedence: bulk I've packaged this up, at least, so that until a port gets here we have a nice ready-to-run version of this (tgdb 1.1). Jordan From owner-freebsd-ports Tue Mar 21 21:27:53 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA21849 for ports-outgoing; Tue, 21 Mar 1995 21:27:53 -0800 Received: from rivers.oscs.montana.edu (rivers.oscs.montana.edu [192.31.215.70]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA21843 for ; Tue, 21 Mar 1995 21:27:52 -0800 Received: by rivers.oscs.montana.edu (5.65/DEC-Ultrix/4.3) id AA11428; Tue, 21 Mar 1995 22:27:45 -0700 Date: Tue, 21 Mar 1995 22:27:45 -0700 (MST) From: Jason Boerner To: Ports@FreeBSD.org Subject: Xpaint port... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk Ok. First off... Thank you to everyone who has helped this FreeBSD newbee get off the gound!!! I'm now starting to get my feet wet with codeing under this platform. I just tried to build the Xpaint port but I ran into a few problems. After fixing a few syntax errors in the source code (How do I re-submit these to the port so that it works for the next person?) I get too the following stage: cc -o xpaint -O2 -L/usr/X11R6/lib main.o menu.o operation.o graphic.o misc.o fileName.o fontSelect.o colorEdit.o pattern.o hash.o palette.o fatBitsEdit.o dialog.o protocol.o size.o text.o cutCopyPaste.o image.o imageComp.o color.o readRC.o iprocess.o help.o typeConvert.o grab.o pencilOp.o boxOp.o lineOp.o circleOp.o brushOp.o fontOp.o arcOp.o polyOp.o fillOp.o selectOp.o sprayOp.o blobOp.o Paint.o Colormap.o PaintRegion.o PaintUndo.o PaintEvent.o rw/librw.a -lXpm -ltiff -lXaw -lXmu -L/usr/X11R6/lib -lXt -lX11 -lXt -lSM -lICE -lXExExt -lXext -lX11 -lm ld: -lXpm: no match *** Error code 1 I assume that this problem has something to do with some type of dynamic library that I am missing (Xpm and probably most of the others listed above). How do I go about obtaining it? I do not see such a beast in the source tree for xpaint. I also suspect that this is why when I try to run xpaint from a packages distribution I recieve the error message: ld.so: xpaint: libXpm.so.3.4: Undefined error: 0 Am I correct? How do I fix it? Thank You From owner-freebsd-ports Tue Mar 21 22:00:56 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA22411 for ports-outgoing; Tue, 21 Mar 1995 22:00:56 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA22404 for ; Tue, 21 Mar 1995 22:00:46 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id WAA11997; Tue, 21 Mar 1995 22:00:29 -0800 Date: Tue, 21 Mar 1995 22:00:29 -0800 Message-Id: <199503220600.WAA11997@silvia.HIP.Berkeley.EDU> To: chaos@rivers.oscs.montana.edu CC: Ports@FreeBSD.org In-reply-to: (message from Jason Boerner on Tue, 21 Mar 1995 22:27:45 -0700 (MST)) Subject: Re: Xpaint port... From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * Ok. First off... Thank you to everyone who has helped this FreeBSD * newbee get off the gound!!! You're welcome! (Well I didn't help you but I always say "you're welcome" to thankers! :) * After fixing a few syntax errors in the source code (How do I re-submit * these to the port so that it works for the next person?) I get too the You can send mail to ports@freebsd.org (as you did) and tell us where we can find your corrections. Preferably in a context diff format that we can put under the patches/ subdirectory, but anything is fine. However, as far as I can tell, xpaint has compiled correctly on our box without any problems. Can you try to re-ftp it from ftp.freebsd.org and try again? * ld: -lXpm: no match * ld.so: xpaint: libXpm.so.3.4: Undefined error: 0 * * Am I correct? How do I fix it? You are correct, and all you need to do is to get the xpm port/package and install it. :) It's in ports/graphics (you can see that in your xpaint toplevel Makefile -- under the variable LIB_DEPENDS). By the way, you may want to follow the instructions that show up when you "cd ports" on ftp.freebsd.org. If you had gotten the new bsd.port.mk file, "make" would have done this for you (assuming you already have ftp'd the xpm port, of course). If you want to play with X, getting the whole ports/graphics subtree now is not a bad idea, 'cause many utilities need something under it and the new port scheme will automatically make them as required. Satoshi From owner-freebsd-ports Wed Mar 22 02:04:53 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA29306 for ports-outgoing; Wed, 22 Mar 1995 02:04:53 -0800 Received: from rivers.oscs.montana.edu (rivers.oscs.montana.edu [192.31.215.70]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id CAA29300 for ; Wed, 22 Mar 1995 02:04:51 -0800 Received: by rivers.oscs.montana.edu (5.65/DEC-Ultrix/4.3) id AA11778; Wed, 22 Mar 1995 03:04:43 -0700 Date: Wed, 22 Mar 1995 03:04:43 -0700 (MST) From: Jason Boerner To: ports@FreeBSD.org Subject: Fixed xpm ports... I think... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk xpm has been through a version upgrade to 3.4e In order to get the port to work I just changed: DISTNAME= xpm-3.4d to: DISTNAME= xpm-3.4e In /usr/ports/graphics/xdm/Makefile Everything seems to work. Since I am completely new to this stuff I am sure that I am doing something risky and nieve but hey. I can now play with some of the X stuff :-)... Am I reporting this correctly? Thanks From owner-freebsd-ports Wed Mar 22 02:05:42 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA29367 for ports-outgoing; Wed, 22 Mar 1995 02:05:42 -0800 Received: (from jmacd@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA29360 for ports; Wed, 22 Mar 1995 02:05:42 -0800 Date: Wed, 22 Mar 1995 02:05:42 -0800 From: Joshua Peck Macdonald Message-Id: <199503221005.CAA29360@freefall.cdrom.com> To: ports Subject: tgdb Sender: ports-owner@FreeBSD.org Precedence: bulk whether this is a tgdb bug or a freebsd-port bug I am not sure, but I was just trying out the help file that comes with tgdb, by clicking on help, selecting TGDB, then on the first page of help I clicked on the top-left button, TOC, and get a segmentation fault, saying there is an error in a Tcl script. just thought I'd mention it, kind of discouraging when the second fifth button you press causes a seg fault, but it *looks* impressive. -josh From owner-freebsd-ports Wed Mar 22 03:03:56 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA01798 for ports-outgoing; Wed, 22 Mar 1995 03:03:56 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA01785 for ; Wed, 22 Mar 1995 03:03:53 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id DAA14050; Wed, 22 Mar 1995 03:03:28 -0800 Date: Wed, 22 Mar 1995 03:03:28 -0800 Message-Id: <199503221103.DAA14050@silvia.HIP.Berkeley.EDU> To: chaos@rivers.oscs.montana.edu CC: ports@FreeBSD.org In-reply-to: (message from Jason Boerner on Wed, 22 Mar 1995 03:04:43 -0700 (MST)) Subject: Re: Fixed xpm ports... I think... From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * xpm has been through a version upgrade to 3.4e * Everything seems to work. Since I am completely new to this stuff I am * sure that I am doing something risky and nieve but hey. I can now * play with some of the X stuff :-)... I tried it myself, it seems to be working fine. Haven't tested it too much but the old version isn't available on the master ftp site so there isn't much point in having the old one lying around anyway. * Am I reporting this correctly? Why thanks, that's excellent. I just updated the ports stuff on our main repository. Unfortunately, our compile server is down so the package may take a little longer. Satoshi From owner-freebsd-ports Wed Mar 22 05:42:17 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA05303 for ports-outgoing; Wed, 22 Mar 1995 05:42:17 -0800 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA05213; Wed, 22 Mar 1995 05:39:12 -0800 Received: from rks32.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA20372; Wed, 22 Mar 95 05:33:15 -0800 Received: by rks32.pcs.dec.com (Smail3.1.27.1 #16) id m0rrQUr-0005OqC; Wed, 22 Mar 95 14:30 MEZ Message-Id: To: jmacd%freefall.cdrom.com@inet-gw-1.pa.dec.com Cc: ports%freebsd.org@inet-gw-1.pa.dec.com, chuckr%Glue.umd.edu@inet-gw-1.pa.dec.com, hackers%freebsd.org@inet-gw-1.pa.dec.com In-Reply-To: Message from Joshua Peck Macdonald of Wed, 22 Mar 95 02:05:42 PST. Reply-To: gj@FreeBSD.org Subject: Re: tgdb Date: Wed, 22 Mar 95 13:30:49 GMT From: "gj%pcs.dec.com@inet-gw-1.pa.dec.com" Sender: ports-owner@FreeBSD.org Precedence: bulk > whether this is a tgdb bug or a freebsd-port bug I am not sure according to the INSTALL file which comes with tgdb this is a bug in BLT-1.7 (I assume you're using this version of BLT). The author recommends using BLT-1.3 for this reason. Unfortunately, BLT-1.3 doesn't seem to exist on any archive machines any longer :( As Chuck Robey wrote: > Amancio: BLT-1.7 does indeed cause the help screen to die. I can't find > a location on BLT-1.3 with archie...d'you happen to know of one? I think I still have BLT-1.3 at home from when I generated tgdb_wish. I'll look around and stick in incoming on ftp.cdrom.com tomorrow, if I find it. BTW I'm in Germany, so tomorrow for me means the middle of the night in the USA. Gary J. From owner-freebsd-ports Wed Mar 22 08:07:10 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA07964 for ports-outgoing; Wed, 22 Mar 1995 08:07:10 -0800 Received: from glueserv1.umd.edu (glueserv1.umd.edu [129.2.70.69]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA07956; Wed, 22 Mar 1995 08:07:07 -0800 Received: from mocha.eng.umd.edu (mocha.eng.umd.edu [129.2.98.16]) by glueserv1.umd.edu (8.6.10/8.6.4) with ESMTP id KAA00986; Wed, 22 Mar 1995 10:42:17 -0500 Received: (chuckr@localhost) by mocha.eng.umd.edu (8.6.10/8.6.4) id KAA13557; Wed, 22 Mar 1995 10:42:17 -0500 Date: Wed, 22 Mar 1995 10:42:16 -0500 (EST) From: Chuck Robey To: Joshua Peck Macdonald cc: ports@freefall.cdrom.com Subject: Re: tgdb In-Reply-To: <199503221005.CAA29360@freefall.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk On Wed, 22 Mar 1995, Joshua Peck Macdonald wrote: > > whether this is a tgdb bug or a freebsd-port bug I am not sure, but > I was just trying out the help file that comes with tgdb, by clicking > on help, selecting TGDB, then on the first page of help I clicked on > the top-left button, TOC, and get a segmentation fault, saying there > is an error in a Tcl script. just thought I'd mention it, kind of > discouraging when the second fifth button you press causes a seg fault, > but it *looks* impressive. > > -josh The documentation states that the blt version 1.7 causes the core dump there, and it's been written up here too.... we knew about it. I can't find the blt version 1.3 anywhere around, and I haven't found the bug involved yet, but its supposedly in the new blt, if that's of any help. Take a look, its in the doc, I think maybe the Install doc. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 7608 Topton St. | New Carrollton, MD 20784 | I run Journey2 (Freebsd 2.0) and n3lxx (301) 459-2316 | (FreeBSD 1.1.5.1) and am I happy! ----------------------------+----------------------------------------------- From owner-freebsd-ports Wed Mar 22 08:34:32 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA08477 for ports-outgoing; Wed, 22 Mar 1995 08:34:32 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA08470; Wed, 22 Mar 1995 08:34:30 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: Jason Boerner cc: ports@FreeBSD.org Subject: Re: Fixed xpm ports... I think... In-reply-to: Your message of "Wed, 22 Mar 95 03:04:43 MST." Date: Wed, 22 Mar 1995 08:34:30 -0800 Message-ID: <8469.795890070@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > xpm has been through a version upgrade to 3.4e > In order to get the port to work I just changed: > DISTNAME= xpm-3.4d > > to: > DISTNAME= xpm-3.4e Yup, it's very frequently that easy! > Everything seems to work. Since I am completely new to this stuff I am > sure that I am doing something risky and nieve but hey. I can now No, it's in fact designed to be as easy as this. You did precisely the right thing - bump the version number next, try to see if the changes still apply, go with it if so. Actually, a purist would probably also move the patches files temporarily out of the way to see if if the changes have become obsolete (sometimes they get folded back into subsequent versions by the authors), but that's not critical (unless they fail to apply :-). > Am I reporting this correctly? Yes! We'll make this change too, thanks. Jordan From owner-freebsd-ports Wed Mar 22 08:44:42 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA08727 for ports-outgoing; Wed, 22 Mar 1995 08:44:42 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA08720; Wed, 22 Mar 1995 08:44:40 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: Joshua Peck Macdonald cc: ports@freefall.cdrom.com Subject: Re: tgdb In-reply-to: Your message of "Wed, 22 Mar 95 02:05:42 PST." <199503221005.CAA29360@freefall.cdrom.com> Date: Wed, 22 Mar 1995 08:44:39 -0800 Message-ID: <8719.795890679@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > whether this is a tgdb bug or a freebsd-port bug I am not sure, but > I was just trying out the help file that comes with tgdb, by clicking > on help, selecting TGDB, then on the first page of help I clicked on > the top-left button, TOC, and get a segmentation fault, saying there Boy, you scored a bullseye there! Yeah, there's some sort of problem. It looks like there's a genuine error in the tgdb distribution's tcl stuff someplace and tgdb_wish's ability to show the backtrace is itself broken somehow, so we segv. Sounds like we need a fix for both! Time for a port version so we can debug this, folks! Hey! Why are you all running away? :-) Jordan From owner-freebsd-ports Wed Mar 22 08:45:18 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA08757 for ports-outgoing; Wed, 22 Mar 1995 08:45:18 -0800 Received: from devnull.mpd.tandem.com (devnull.mpd.tandem.com [131.124.4.29]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA08743; Wed, 22 Mar 1995 08:45:12 -0800 Received: from olympus by devnull.mpd.tandem.com (8.6.8/8.6.6) id KAA28586; Wed, 22 Mar 1995 10:44:45 -0600 Received: by olympus (4.1/TSS2.1) id AA21521; Wed, 22 Mar 95 10:43:11 CST From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9503221643.AA21521@olympus> Subject: Re: Where are all the database weenies when you need them? :-) To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Mar 1995 10:43:11 -0600 (CST) Cc: ports@freefall.cdrom.com In-Reply-To: <199503212353.PAA10912@freefall.cdrom.com> from "Jordan K. Hubbard" at Mar 21, 95 03:53:43 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 523 Sender: ports-owner@FreeBSD.org Precedence: bulk > > ports/db: > msql > > That's pretty thin, guys! What happened to ingres? postgres? outgres? > throughgres? At least _one_ other database sure wouldn't hurt! Any > Minerva fans out there? > > Jordan > I though msql WAS Minerva. Her picture is on the manual. Amazing likeness. Boyd -- _______________________________________________________________________ Boyd Faulkner faulkner@isd.tandem.com _______________________________________________________________________ From owner-freebsd-ports Wed Mar 22 09:09:37 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA09597 for ports-outgoing; Wed, 22 Mar 1995 09:09:37 -0800 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA09591; Wed, 22 Mar 1995 09:09:36 -0800 Received: from freefall.cdrom.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA02699; Wed, 22 Mar 95 09:01:43 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA09215; Wed, 22 Mar 1995 09:01:50 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: gj@FreeBSD.org Cc: jmacd%freefall.cdrom.com@inet-gw-1.pa.dec.com, ports%freebsd.org@inet-gw-1.pa.dec.com, chuckr%Glue.umd.edu@inet-gw-1.pa.dec.com, hackers%freebsd.org@inet-gw-1.pa.dec.com Subject: Re: tgdb In-Reply-To: Your message of "Wed, 22 Mar 95 13:30:49 GMT." Date: Wed, 22 Mar 1995 09:01:50 -0800 Message-Id: <9214.795891710@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk Of course, we could always just try to fix the bug in BLT-1.7! :-) Jordan > > whether this is a tgdb bug or a freebsd-port bug I am not sure > > according to the INSTALL file which comes with tgdb this is a bug in > BLT-1.7 (I assume you're using this version of BLT). The author recommends > using BLT-1.3 for this reason. > > Unfortunately, BLT-1.3 doesn't seem to exist on any archive machines any > longer :( > > As Chuck Robey wrote: > > > Amancio: BLT-1.7 does indeed cause the help screen to die. I can't find > > a location on BLT-1.3 with archie...d'you happen to know of one? > > I think I still have BLT-1.3 at home from when I generated tgdb_wish. I'll > look around and stick in incoming on ftp.cdrom.com tomorrow, if I find it. > BTW I'm in Germany, so tomorrow for me means the middle of the night in the > USA. > > Gary J. From owner-freebsd-ports Wed Mar 22 09:13:46 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA09853 for ports-outgoing; Wed, 22 Mar 1995 09:13:46 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA09846; Wed, 22 Mar 1995 09:13:45 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: Joshua Peck Macdonald Cc: ports@freefall.cdrom.com Subject: Re: tgdb In-reply-to: Your message of "Wed, 22 Mar 95 08:44:39 PST." <8719.795890679@freefall.cdrom.com> Date: Wed, 22 Mar 1995 09:13:44 -0800 Message-ID: <9844.795892424@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk I should read more - as clearly indicated later, we need to fix BLT. Disregard this: > > whether this is a tgdb bug or a freebsd-port bug I am not sure, but > > I was just trying out the help file that comes with tgdb, by clicking > > on help, selecting TGDB, then on the first page of help I clicked on > > the top-left button, TOC, and get a segmentation fault, saying there > > Boy, you scored a bullseye there! > > Yeah, there's some sort of problem. It looks like there's a genuine > error in the tgdb distribution's tcl stuff someplace and tgdb_wish's > ability to show the backtrace is itself broken somehow, so we segv. > Sounds like we need a fix for both! Time for a port version so we can > debug this, folks! Hey! Why are you all running away? :-) > > Jordan From owner-freebsd-ports Wed Mar 22 09:14:31 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA09884 for ports-outgoing; Wed, 22 Mar 1995 09:14:31 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA09877; Wed, 22 Mar 1995 09:14:30 -0800 X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol To: faulkner@mpd.tandem.com (Boyd Faulkner) cc: ports@freefall.cdrom.com Subject: Re: Where are all the database weenies when you need them? :-) In-reply-to: Your message of "Wed, 22 Mar 95 10:43:11 CST." <9503221643.AA21521@olympus> Date: Wed, 22 Mar 1995 09:14:30 -0800 Message-ID: <9876.795892470@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk I was under the impression that Minerva sat on top of multiple databases as a sort of pan-SQL solution. Jordan > > > > ports/db: > > msql > > > > That's pretty thin, guys! What happened to ingres? postgres? outgres? > > throughgres? At least _one_ other database sure wouldn't hurt! Any > > Minerva fans out there? > > > > Jordan > > > I though msql WAS Minerva. Her picture is on the manual. Amazing likeness. > > Boyd > > -- > _______________________________________________________________________ > > Boyd Faulkner faulkner@isd.tandem.com > _______________________________________________________________________ From owner-freebsd-ports Wed Mar 22 11:31:41 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA12658 for ports-outgoing; Wed, 22 Mar 1995 11:31:41 -0800 Received: from devnull.mpd.tandem.com (devnull.mpd.tandem.com [131.124.4.29]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA12652; Wed, 22 Mar 1995 11:31:34 -0800 Received: from olympus by devnull.mpd.tandem.com (8.6.8/8.6.6) id NAA06423; Wed, 22 Mar 1995 13:31:06 -0600 Received: by olympus (4.1/TSS2.1) id AA22108; Wed, 22 Mar 95 13:29:37 CST From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9503221929.AA22108@olympus> Subject: Re: Where are all the database weenies when you need them? :-) To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Mar 1995 13:29:36 -0600 (CST) Cc: faulkner@devnull.mpd.tandem.com, ports@freefall.cdrom.com In-Reply-To: <9876.795892470@freefall.cdrom.com> from "Jordan K. Hubbard" at Mar 22, 95 09:14:30 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1102 Sender: ports-owner@FreeBSD.org Precedence: bulk It appears you are correct. msql is Minerva's choice for backend and was developed for that purpose. Hence the picture. My mistake. Boyd > > I was under the impression that Minerva sat on top of multiple databases > as a sort of pan-SQL solution. > > Jordan > > > > > > > ports/db: > > > msql > > > > > > That's pretty thin, guys! What happened to ingres? postgres? outgres? > > > throughgres? At least _one_ other database sure wouldn't hurt! Any > > > Minerva fans out there? > > > > > > Jordan > > > > > I though msql WAS Minerva. Her picture is on the manual. Amazing likeness. > > > > Boyd > > > > -- > > _______________________________________________________________________ > > > > Boyd Faulkner faulkner@isd.tandem.com > > _______________________________________________________________________ > > -- _______________________________________________________________________ Boyd Faulkner faulkner@isd.tandem.com _______________________________________________________________________ From owner-freebsd-ports Wed Mar 22 12:49:19 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA14365 for ports-outgoing; Wed, 22 Mar 1995 12:49:19 -0800 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA14316; Wed, 22 Mar 1995 12:47:48 -0800 Received: from netcom8.netcom.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA15667; Wed, 22 Mar 95 12:44:06 -0800 Received: by netcom8.netcom.com (8.6.10/Netcom) id MAA22980; Wed, 22 Mar 1995 12:40:10 -0800 Date: Wed, 22 Mar 1995 12:40:10 -0800 From: hasty@netcom.com (Amancio Hasty Jr) Message-Id: <199503222040.MAA22980@netcom8.netcom.com> To: gj@FreeBSD.org, jmacd%freefall.cdrom.com@inet-gw-1.pa.dec.com Subject: Re: tgdb Cc: chuckr%Glue.umd.edu@inet-gw-1.pa.dec.com, hackers%freebsd.org@inet-gw-1.pa.dec.com, ports%freebsd.org@inet-gw-1.pa.dec.com Sender: ports-owner@FreeBSD.org Precedence: bulk You can blt-1.3 at: ftp.best.com:/pub/hasty/BLT-1.3.tar.gz Amancio From owner-freebsd-ports Wed Mar 22 13:28:14 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA15286 for ports-outgoing; Wed, 22 Mar 1995 13:28:14 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA15274 for ; Wed, 22 Mar 1995 13:28:09 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.11/jtpda-5.0) with SMTP id WAA21199 ; Wed, 22 Mar 1995 22:28:05 +0100 Received: by blaise.ibp.fr (4.1/SMI-4.1) id AA04233; Wed, 22 Mar 95 22:27:49 +0100 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <9503222127.AA04233@blaise.ibp.fr> Subject: Re: How too??? To: chaos@rivers.oscs.montana.edu (Jason Boerner) Date: Wed, 22 Mar 1995 22:27:48 +0100 (MET) Cc: ports@FreeBSD.org In-Reply-To: from "Jason Boerner" at Mar 21, 95 01:57:48 pm X-Operating-System: FreeBSD 2.1.0-Development ctm#429 X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 489 Sender: ports-owner@FreeBSD.org Precedence: bulk > I read the FAQ in /usr/share/FAQ but was unable to answer the most > important question. How? How do I pull ports over ftp without having to > re-create (by hand) every subdirectory in the ports collection and > performing an mget * for each of them? ftp> cd /pub/FreeBSD-current ftp> get ports.tar.gz fetch the directory as .tar.gz. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.1.0-Development #1: Mon Mar 6 23:55:18 MET 1995 From owner-freebsd-ports Wed Mar 22 15:46:56 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA18687 for ports-outgoing; Wed, 22 Mar 1995 15:46:56 -0800 Received: from goof.com (root@goof.com [198.82.204.15]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA18681 for ; Wed, 22 Mar 1995 15:46:55 -0800 Received: (from mmead@localhost) by goof.com (8.6.11/8.6.9) id SAA01675 for ports@freebsd.org; Wed, 22 Mar 1995 18:46:43 -0500 From: "matthew c. mead" Message-Id: <199503222346.SAA01675@goof.com> Subject: xview3.2 X11R6 To: ports@FreeBSD.org Date: Wed, 22 Mar 1995 18:46:43 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 578 Sender: ports-owner@FreeBSD.org Precedence: bulk I have a majorly overhauled and cleaned up version of xview3.2 sitting on my system. Would anyone (including the porter of what's already there) mind replacing xview-lib xview-config and xview-clients with what I've got? If so, what all do I do to commit it? -matt -- Matthew C. Mead -> Virginia Tech Center for Transportation Research - -> Multiple Platform System and Network Administration Work Related -> mmead@ctr.vt.edu | mmead@goof.com <- All Other ---- ------- WWW -> http://www.goof.com/~mmead --- ----- From owner-freebsd-ports Wed Mar 22 17:48:59 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA22754 for ports-outgoing; Wed, 22 Mar 1995 17:48:59 -0800 Received: from glueserv1.umd.edu (glueserv1.umd.edu [129.2.70.69]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA22748; Wed, 22 Mar 1995 17:48:58 -0800 Received: from latte.eng.umd.edu (latte.eng.umd.edu [129.2.98.15]) by glueserv1.umd.edu (8.6.10/8.6.4) with ESMTP id UAA20883; Wed, 22 Mar 1995 20:48:45 -0500 Received: (chuckr@localhost) by latte.eng.umd.edu (8.6.10/8.6.4) id UAA28453; Wed, 22 Mar 1995 20:48:45 -0500 Date: Wed, 22 Mar 1995 20:48:44 -0500 (EST) From: Chuck Robey To: Boyd Faulkner cc: "Jordan K. Hubbard" , faulkner@devnull.mpd.tandem.com, ports@freefall.cdrom.com Subject: Re: Where are all the database weenies when you need them? :-) In-Reply-To: <9503221929.AA22108@olympus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk On Wed, 22 Mar 1995, Boyd Faulkner wrote: > It appears you are correct. msql is Minerva's choice for backend and was > developed for that purpose. Hence the picture. My mistake. > > Boyd > > > > I was under the impression that Minerva sat on top of multiple databases > > as a sort of pan-SQL solution. > > > > Jordan > > > > > > > > > > ports/db: > > > > msql > > > > > > > > That's pretty thin, guys! What happened to ingres? postgres? outgres? > > > > throughgres? At least _one_ other database sure wouldn't hurt! Any > > > > Minerva fans out there? > > > > > > > > Jordan > > > > > > > I though msql WAS Minerva. Her picture is on the manual. Amazing likeness. > > > > > > Boyd from the Catalog of Free Databases: name: mSQL (Mini SQL) version: 1.0.2 interfaces: C, ESL, Tcl, Perl, Python, NextSTEP adapter, Windows (WinSOCK) access methods: Flat data with external primary key mapped into virtual address space of server process. multiuser: yes (25 simultaneous connections) transactions: no distributed: no query language: SQL limits: none robustness: Pretty good - getting better all the time description: Mini SQL or mSQL is a light weight database engine that supports a significant subset of the ANSI SQL specification (including joins, ORDERing, DISTINCT, NULL handling, etc). It is a single proces engine and doesn't use vast amounts of system resources as other engines can. It supports client server operations over TCP/IP networks and provides quite reasonable performance. As an example, on a clunky old 25mhz 386 running Linux (one of the supported platforms) a sustained rate of 67 inserts per second was achieved during the insertion of 100,000 table entries. discussion: msql-list-request@Bond.edu.au ports: Supported under Linux, SunOS, Solaris, Ultrix, FreeBSD 2 Known to work under NeXT, Irix, HP-UX, OSF/1, Sequent, SVR4.2, SCO, AIX restrictions: ? author: David Hughes how to get: ftp pub/Minerva/msql/ from Bond.edu.au updated: 1995/01/18 The rest of this, I think, is available on idiom.com. Neat listing. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 7608 Topton St. | New Carrollton, MD 20784 | I run Journey2 (Freebsd 2.0) and n3lxx (301) 459-2316 | (FreeBSD 1.1.5.1) and am I happy! ----------------------------+----------------------------------------------- From owner-freebsd-ports Wed Mar 22 18:12:38 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA23834 for ports-outgoing; Wed, 22 Mar 1995 18:12:38 -0800 Received: from glueserv1.umd.edu (glueserv1.umd.edu [129.2.70.69]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA23828; Wed, 22 Mar 1995 18:12:29 -0800 Received: from latte.eng.umd.edu (latte.eng.umd.edu [129.2.98.15]) by glueserv1.umd.edu (8.6.10/8.6.4) with ESMTP id VAA21438; Wed, 22 Mar 1995 21:12:17 -0500 Received: (chuckr@localhost) by latte.eng.umd.edu (8.6.10/8.6.4) id VAA28823; Wed, 22 Mar 1995 21:12:16 -0500 Date: Wed, 22 Mar 1995 21:12:15 -0500 (EST) From: Chuck Robey To: Boyd Faulkner cc: "Jordan K. Hubbard" , faulkner@devnull.mpd.tandem.com, ports@freefall.cdrom.com Subject: Re: Where are all the database weenies when you need them? :-) In-Reply-To: <9503221929.AA22108@olympus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk I had it suggested to me that you gusy might be interested in this: it's the guide to free databases. The header says how to get updates, I usually snag mine offa the newsgroups. Enjoy! From: David Muir Sharnoff Newsgroups: comp.databases,comp.databases.object,comp.os.386bsd.apps,comp.os.linux.development.apps,gnu.misc.discuss,comp.answers,news.answers Subject: Catalog of free database systems Supersedes: Message-ID: Followup-To: comp.databases Reply-To: free-databases@idiom.com Date: 5 Feb 1995 16:50:52 -0800 Expires: Fri, 11 Aug 1995 23:59:00 GMT Approved: news-answers-request@mit.edu Organization: Idiom Consulting Lines: 2136 Xref: mojo.eng.umd.edu comp.databases:42466 comp.databases.object:4699 comp.os.386bsd.apps:1855 comp.os.linux.development.apps:1016 gnu.misc.discuss:21137 comp.answers:9835 news.answers:37427 Archive-name: databases/free-databases Last-modified: 1995/02/05 Version: 1.13 Catalog of Free Database Systems This document attemts to catalog databases that are available without payment and with source. The latest version of the document can be ftp'ed: get pub/free-databases from ftp.idiom.com. There is a WWW version provided by Karl Guggisberg of the Software Composition Group: http://cui_www.unige.ch/~scg/FreeDB/ I will post this document about once a month (ha!) to comp.databases, comp.databases.object, comp.answers, and news.answers. I will also post it to other groups somewhat randomly. Please send additions, corrections, and donations to David Muir Sharnoff I would like user testimonials. I want to know which databases are usable and which are trustable! Is there any database on this list that I could store payroll records on? Thanks, -Dave Idiom Consulting, Berkeley, CA Copyright (C) 1993-1995 David Muir Sharnoff, All rights reserved. --------------------------------------------------------------------------- Prototype entry: name: The name of the package version: The current version number of the package direct inquiries to "contact." interface from: (interface packages only) front end protocol/program/language interface to: (interface packages only) back end protocol/program/server/etc. interfaces: The external interfaces that are supported by the package. Common interfaces are: SQL, ESQL, dbm, X, etc. access methods: A list of the database access methods that are supported multiuser: Can more than one person access the package at the same time. transactions: Does the package support transactions? distributed: Does the package support distributed databases? query language: What query languages does the package support if any? SQL, QUEL, etc. index size: (full text packages only) the size of the index as a percentage of the size of the text to be indexed. limits: Any known, annoying limits robustness: Can this package be used on mission-critical data? Is the package bug free? Does it crash? If it supports multi-user transactions, does it make guarentees and keep them? description: A description of the package. references: Pointers to other documentation (not including that which is included in the package) status: current developement status (supported, actively developed, etc) announcements: Where to get announcements discussion: Where to send, or how to join discussions about the package bugs: Where to send bug reports requires: Special requirements for installing or running ports: What does the package run on? restrictions: Special copyright or other restrictions on the software author: The primary author, if known. If not known, contact: The current contact point. If not specified, use "author." how to get: Instructions for obtaining the package updated: When the package was last updated (yyyy/mm/dd) --------------------------------------------------------------------------- Selected changes: new listings: Essence - resource discovery system w/full text indexes FFW - Freetext search For Web. inverted index, CGI interface PQL - relational (SQL subset) database based on GDBM YOODA - a distributed object-oriented database in C++ updates: DiamondBase 0.31 is available grok 1.1 is available mSQL 1.0.2 is available OBST3 4.3 is available Onyx 2.34 is available Qddb 1.41.9 patch 4 is available Typhoon 1.06 is available --------------------------------------------------------------------------- --------------------------- relational databases -------------------------- --------------------------------------------------------------------------- name: DiamondBase version: 0.31 interfaces: C++ library access methods: b+ tree multiuser: Beta in this version transactions: no distributed: no query language: C++ methods limits: limits are set at compile time. The default max records is 21474836. robustness: The database engine is quite stable. The multi user component is a more recent addition, and is still considered beta. The single user version is separate however and unaffected. description: DiamondBase is written entirely in C++, and uses a schema compiler to generate C++ class defintions for the objects, as well as some comparison code which is also linked in to the final executable. Facilities are now available to access generic relations without providing comparison code. It was written originally as a replacement for MetalBase which was too slow. DiamondBase is very fast. announcements: send mail to Darren Platt to be put on their list questions: send mail to Darren Platt bugs: send mail to Darren Platt requires: C++ ports: many Unix platforms and OS/2 under cfront or gcc or Borland's compiler. Recent ports to Dos/windows. restrictions: Free usage for non-commerical applications -- negotiate anything else. author: Kevin Lentin, Andrew Davison, Darren Platt contact: Darren Platt how to get: ftp pub/export/diamond.tar.gz from ftp.cs.monash.edu.au updated: 1994/12/22 name: PQL version: 0.7 prebeta interfaces: interactive, stdin and shell mode access methods: hash multiuser: no transactions: yes distributed: no query language: SQL subset limits: ? robustness: Still undergoing initial public testing description: PQL stands for "plain query language" and is a kind of SQL (rather a subset) Nearly all features of SQL are supported, like joins, subqueries and grouping. The join operation has been optimized using a iterative "select and join" algorithm which runs over all joined base tables. In addition to the PQL-Interpreter, a relational and transaction oriented database engin e interface is shipped with the package. The engine is based on the lower level GDBM interface, a freely available database library. bugs: author requires: gdbm, GNU readline ports: unix author: Bjoern Lemke how to get: ftp pub/unix/database from info2.rus.uni-stuttgart.de updated: 1995/01/20 name: Qddb version: 1.41.9 patch 4 interfaces: query language, Tcl/Tk access methods: ? multiuser: yes transactions: ? distributed: no query language: supports regular expressions; words, numbers, and dates; and ranges of words, numbers, and dates. limits: ? robustness: This is BETA software, but we have been happily using the underlying stuff for years. description: QDDB stands for 'Quick and Dirty DataBase'. Qddb is a database suite that allows you to create relations, add tuples, modify tuples, delete tuples, and search for tuples in a fast and very flexible way. Qddb 1.40 can use Tcl as its configuration language, so you can build custom interfaces to your Qddb databases with it. We provide a reasonably nice generic interface so you can be up and running quickly. status: actively developed discussion: send "Subject: subscribe" with your address in the body to qddb-users-request@ms.uky.edu bugs: qddb-bugs@ms.uky.edu and qddb-users@ms.uky.edu requires: Tcl 7.3, Tk 3.6p1 ports: Ultrix, OSF/1, BSD/386, Linux, SunOS, Solaris. restrictions: GNU General Public License author: Eric H. Herrin II , Raphael Finkel how to get: ftp pub/unix/qddb/ from ftp.ms.uky.edu updated: 1995/02/03 name: Typhoon version: 1.06 interfaces: C API access methods: B-trees multiuser: Yes, but no locking mechanism at this point (will come soon) transactions: no distributed: no query language: none limits: A single file cannot exceed 4GB. robustness: The package is quite stable as it is shut down properly. It is currently used in a system that handles billing information (and some other applications). description: Typhoon is a relational database management system. It was originally inspired by Raima's db_VISTA (today Raima Data Manager) but is relational rather than network based. Typhoon lacks some of db_VISTA's features, but also contains a number of nice features not found in db_VISTA. All relations are defined in a so called Data Definition Language (ddl) file. You define the database relations like you would write a C structure with chars, ints, strings, multidimensional arrays, nested union and structures, etc. Then you define primary, alternate and foreign keys for each relation. The Data Definition Language Processor (ddlp) compiles the database defintion into a binary file which constitutes the database description. The database relations are accessed via C subroutines which manipulate individual records within a table. - Multiple open database - Multi-field keys - Nested structures in records - Controlled unions - Referential integrity - Variable length fields - Null keys (optional keys in db_VISTA, but easier to use) - Dynamic opening and closing of database files status: actively developed ports: SCO UNIX, Solaris, Tandem NonStop UNIX, AIX, Linux and OS/2. author: Thomas B. Pedersen how to get: comp.sources.misc volume 44; ftp pub/Linux/devel/db/typhoon-1.06.tar.gz from sunsite.unc.edu updated: 1994/10/03 name: University INGRES version: 8.9 interfaces: QUEL, EQUEL access methods: heap, hash, isam, ordered multiuser: yes transactions: yes, but no multistatement transactions. Each statement is ACID distributed: no query language: QUEL limits: ? robustness: Very mature technology description: This is the database program that was the basis for INGRES Corporation. Obviously, it does not have all the bells and whistles of the current commercial product. However, it is small and fast and it works. So called ordered relations are slow and not locked. references: "The INGRES Papers" Stonebraker ed. Addison Wesley ports: SunOS, Linux author: The Ingres project at UC Berkeley. contact: how to get: ftp pub/ingres/* from s2k-ftp.CS.Berkeley.EDU updated: 1993/05/20 name: MetalBase version: 5.0 interfaces: custome C library access methods: AVL-trees multiuser: yes, but in theory race conditions still exist transactions: yes distributed: no query language: "Report", and "View Relation" a curses based viewer limits: ? robustness: data corruption is possible when MetalBase is not shut down correctly description: MetalBase is a small relational database. It has all the pieces that a relational database should C interface, curses interface, report writer, etc. It does not have design which takes advantage of shared memory or the better access methods. None of the interfaces are standard, but all of them are easy to use. discussion: mbase-request@internode.com.au requires: curses ports: Linux, MS-DOS, Amiga, NeXT, Coherent, Macintosh MPW, SGI, Xenix restrictions: donations are suggested author: Richid Jernigan / PO Box 827 / Norris TN 37828 how to get: ftp systems/unix/linux/sources/usr.bin/mbase.tar.z from ftp.uu.net updated: 1992/10/01 name: mSQL (Mini SQL) version: 1.0.2 interfaces: C, ESL, Tcl, Perl, Python, NextSTEP adapter, Windows (WinSOCK) access methods: Flat data with external primary key mapped into virtual address space of server process. multiuser: yes (25 simultaneous connections) transactions: no distributed: no query language: SQL limits: none robustness: Pretty good - getting better all the time description: Mini SQL or mSQL is a light weight database engine that supports a significant subset of the ANSI SQL specification (including joins, ORDERing, DISTINCT, NULL handling, etc). It is a single proces engine and doesn't use vast amounts of system resources as other engines can. It supports client server operations over TCP/IP networks and provides quite reasonable performance. As an example, on a clunky old 25mhz 386 running Linux (one of the supported platforms) a sustained rate of 67 inserts per second was achieved during the insertion of 100,000 table entries. discussion: msql-list-request@Bond.edu.au ports: Supported under Linux, SunOS, Solaris, Ultrix, FreeBSD 2 Known to work under NeXT, Irix, HP-UX, OSF/1, Sequent, SVR4.2, SCO, AIX restrictions: ? author: David Hughes how to get: ftp pub/Minerva/msql/ from Bond.edu.au updated: 1995/01/18 name: Postgres version: 4.2 beta interfaces: libpq (C interface), pgbrowse (tk-based browser) access methods: Heap plus secondary indexes: B-tree, R-tree, Hash. multiuser: yes transactions: yes distributed: no query language: Postquel (incompatable, extended variant of QUEL) limits: ? robustness: The authors say: "It is not up to commercial levels of reliability. I would not want _my_ payroll records in it :-)" description: Postgres is a database research project under Prof. Michael Stonebraker at U. C. Berkeley. To facilitate research efforts, a software test-bed was created; this is the "Postgres" DBMS software. The Postgres DBMS is extended relational or object oriented, depending on the buzzword du jour. Postgres is relational. It is highly extensible. It has object oriented features like inheritance. it has query language procedures, rules, updatable views, and more. references: There are may papers available, both through ftp and as hard-copy technical reports. Cruse the ftp site for papers or mail Michelle Mattera discussion: send "Subject: ADD" to postgres-request@postgres.berkeley.edu linux: send "X-Mn-Admin: join postgres" to linux-activists-request@niksula.hut.fi bugs: ports: full support: Alpha OSF/1 1.3+, Mips Ultrix .2+, Sparc SunOS 4.1.1+, Power AIX 3.2.3+, HP-PA HP-UX 9.0+ comming soon: Sparc Solaris 2.3, i386 Linux previous versions: i386 SVR4, i386 386BSD, i386 Linux, i386 NextStep 3.1, NeXT NextStep 3.0, Sparc Solaris 2.1+, HP-PA HP-UX 8.07 contact: developers: admin: Michelle Mattera how to get: ftp pub/postgres/postgres-v4r2* from s2k-ftp.CS.Berkeley.EDU. pgbrowse: ftp pub/pgbrowse/* from crseo.ucsb.edu. updated: 1994/04/02 name: REQUIEM version: ? interfaces: RQL, ERQL (extension) access methods: B-tree indexes can be created on attributes of base relations. multiuser: yes (multiuser extension) transactions: yes (multiuser extension) distributed: no query language: RQL robustness: [seems to maintained by zero to few people --ed] description: REQUIEM (RElational Query and Update Interactive systEM) is an extensible, relational DBMS developed in C with a query language based on the relational algebra called RQL (Relational Query Language). There appears to be three versions of REQUIEM: the base version and two extensions. One extension adds multiuser capability. The other adds an embeddable version of the query langauge. references: "An Extensible DBMS for Small-Medium Scale Systems", Papazoglou, M.P., IEEE Micro, April 1989. Relational Database Management - A Systems Programming Approach, Papazoglou, M.P. and Valder, W., Prentice Hall International, UK, 1989. "The Development of a Program Interface for the RDBMS Requiem" Power, R.A., 1991 Honours Thesis (dvi file available with source code for the embedded version). ports: Sparc/SunOS; base version only: MS-DOS, Macintosh contact: (embedded version only) Robert Power how to get: ftp pub/requiem/REQUIEM.tar.Z (multiuser version) or pub/requiem/Requiem.tar.Z (embeddable version) from dcssoft.anu.edu.au The base version can be constructed from the multiuser version. updated: 1992/10/06 name: shql version: 1.3 Beta interfaces: SQL, shell multiuser: no transactions: no ? distributed: no limits: no NULLs in the data, spaces and backslashes may be added when the data contains punctuation, GROUP BY is not implemented. robustness: it is a shell script. description: Shql is a program that reads SQL commands interactively and executes those commands by creating and manipulating Unix files. The program is patterned after Ingres' interactive sql terminal monitor program. requires: bourne shell with functions, awk, grep, cut, sort, uniq, join, wc, and sed author: Bruce Momjian how to get: comp.sources.misc volumes 34, 41 and 42. Also ftp pub/net-sources/shql-patch-1.3-beta from ftp.idiom.com updated: 1994/08/06 --------------------------------------------------------------------------- --------------------------- object oriented ------------------------------- --------------------------------------------------------------------------- name: Arjuna Distributed Programming System version: 2.0 interfaces: C++ access methods: ? multiuser: yes transactions: yes, nested distributed: yes, includes replicated objects query language: ? limits: ? robustness: "all reported bugs fixed" description: Arjuna is a programming system for reliable distributed computing. Arjuna supports nested atomic actions for controlling operations on objects (instances of C++ classes), which can potentially be persistent. The software available includes a C++ stub generator which hides much of the details of client-server based programming, plus a system programmer's manual containing details of how to install Arjuna and use it to build fault-tolerant distributed applications. discussion: send "join arjuna YOUR-NAME-HERE" to mailbase@mailbase.ac.uk ports: UNIX: Suns, HPs, etc. restrictions: A commercial extension exists. contact: arjuna@newcastle.ac.uk how to get: ftp pub/Arjuna from arjuna.ncl.ac.uk updated: 1993/05/15 name: EXODUS Project software version: GNU E 2.3.3, Storage Manager (SM) 3.1 interfaces: GNU E, (C++ for direct access to the Storage Manager) access methods: B+tree and linear-hashing based indexes multiuser: yes, client-server transactions: yes, but not nested. distributed: yes, applications can access multiple servers in a single transaction. Distributed commits are performed across servers and clients have access to an interface allowing participation in distributed commits managed by an external agent. query language: GNU E -- a persistent programming language based on C++ robustness: High (at least for academic software). The SM release includes a facility for regression testing most features, including crash recovery. description: The EXODUS Storage Manager (SM) is a client-server object storage system which provides "storage objects" for storing data, versions of objects, "files" for grouping related storage objects, and indexes for supporting efficient object access. A storage object is an uninterpreted container of bytes which can range in size from a few bytes to hundreds of megabytes. The Storage Manager provides routines to read, overwrite, and efficiently grow and shrink objects. In addition, the Storage Manager provides transactions, lock-based concurrency control, and log-based recovery. GNU E is a persistent, object oriented programming language developed as part of the Exodus project. GNU E extends C++ with the notion of persistent data, program level data objects that can be transparently used across multiple executions of a program, or multiple programs, without explicit input and output operations. references: A bibliography of EXODUS related papers can be obtained from the ftp site described below. Some of the papers are available from the ftp server as technical reports, and are marked as such in the bibliography. status: No longer being developed. However, the authors are working on a new system, SHORE, and will support current Exodus users well enough to keep them going until SHORE is useable. GNU E 2.5.8 is in beta and can be ftped. discussion: Send "information exodus_all" to listproc@cs.wisc.edu to find out how to join the exodus_all mailing list. bugs: exodusbugs@cs.wisc.edu requires: g++ 2.3.3 (exactly 2.3.3. GNU E 2.5.8 is in beta) ports: MIPS/Ultrix, SPARC/SunOS, HP 7xx/HP-UX, Linux restrictions: none, but see copyright notice located in all source files author: The EXODUS Database Toolkit project at the University of Wisconsin contact: exodus@cs.wisc.edu how to get: ftp exodus/* from ftp.cs.wisc.edu updated: 1993/03/29 name: LINCKS (Linkoping Intelligent Communication of Knowledge System) version: 2.2.1 interfaces: C library, emacs-like editor/X11 access methods: ? multiuser: yes transactions: no distributed: no, but maybe later query language: hypertext-ish X user interface robustness: The underlaying store handler (NODE) has been used since '89 and is quite stable. The system have betweem 20 to 500 users. description: LINCKS is an object-centred multi-user database system developed for complex information system applications where editing and browsing of information in the database is of paramount importance. The focus is on sharing of small information chunks which combine to make up complex information objects used by different users for different purposes. The information chunks are semi-structured in that they contain one part which is well-structured to facilitate addition of A.I. processing within the system, and one part which is unstructured and suitable for management by the user. Features: shared composite objects, database history, atlernative views, change collision notification (when more than one person makes changes to the same composite object) references: ftp://ftp.ida.liu.se/pub/lincks/articles/cscw.ps.gz announcements: lincks@ida.liu.se discussion: lincks-users-request@ida.liu.se bugs: lincks-bugs@ida.liu.se requires: Unix, X11R5 ports: Sun4/SunOS 4.1.[123], Sun4/SunOS 5.2, Sun3, Decstation, Alpha, RS/6000, Sequent Symmetry, Linux, HP-UX, SGI, SCO, SVR4.2, Sony restrictions: GNU General Public License author: Lin Padgham, Ralph Ronnquist; University of Linkoping, Sweden contact: lincks@ida.liu.se how to get: ftp pub/lincks/lincks-2.2.tar.gz from ftp.ida.liu.se usa: ftp pub/database/lincks/lincks-2.2.tar.gz from ftp.uu.net usa: ftp pub/net/infosys/lincks/lincks-2.2.tar.gz from gatekeeper.dec.com updated: 1994/06/05 name: OBST version: 3-4.3 interfaces: C++, tcl, schema compiler, graphical object browser access methods: extendable hashtable multiuser: yes, but writing locks entire tables transactions: yes distributed: not yet query language: C++, tcl, graphical object browser limits: 4 GB per container, 2^32 containers robustness: OBST is quite stable since the start of '93. Releases were made to enhance the coding quality rather than to add new features. There are somewhere between 50 and 500 users. description: The persistent object management system OBST was developed by Forschungszentrum Informatik (FZI) as a contribution to the STONE project (supported by grant no. ITS8902A7 from the BMFT, i.e. the German Ministry for Research). OBST was originally designed to serve as the common persistent object store for the tools of an software engineering environment. An essential feature of STONE is that the object oriented paradigm is pursued consequently as a key concept. OBST is the common persistent object store for all tools within the STONE environment. OBST provides a rich OO model including multiple inheritance, generics, overloading, and privacy. The schema definition language is syntactically similar to C++. It comes with a library of pre-defined classes like Set, and List. New methods can be incrementally loaded at runtime. announcements: send 'add obst-announce' to obst-listserv@fzi.de discussion: send 'add obst-forum' to obst-listserv@fzi.de bugs: send OBST version, configuration options, C++ version, machine, OS, and a description of your problem to . requires: A C++ compiler (G++ 2.3.3-2.6.3 or AT&T 2.1/3.01) ports: UNIX: SPARC/SunOS 4.1, Solaris 2, Linux, HP-UX, Ultrix, ... contact: obst@fzi.de how to get: ftp pub/OBST/OBST3-4.3 from ftp.fzi.de usa: ftp pub/database/obst/? from ftp.uu.net uk: ftp computing/databases/OBST/? from src.doc.ic.ac.uk updated: 1995/01/19 name: pfl version: 0.2 interfaces: Built-in persistent functional programming language access methods: no multiuser: no transactions: no distributed: no query language: functional programming limits: Index size is limited by the amount of main memory available. Selectors are a bit flaky when they contain more than about 10,000 tuples. Since the current implementation of the language is interpreted it is very slow. robustness: alpha release description: pfl is a persistent programming language and database environment. The language is functional. references: "An Overview of PFL", 3rd International Workshop on Database Programming Languages, 1991. "A functional programming approach to deductive databases", 17th International Conference on Very Large Databases, 1991 bugs: SunOS: author, Linux: Tim Holmes requires: GNU C++ ports: Linux, SunOS restrictions: GNU General Public License; educational use ? author: Carol Small contact: Tim Holmes how to get ftp pub/Linux/ALPHA/pfl-0.2.tgz from sunsite.unc.edu updated: 1994/09/21 name: The Texas Persistent Store version: 0.1 interfaces: C++ library access methods: ? multiuser: not yet transactions: not yet distributed: not yet query language: ? limits: ? robustness: beta software description: Texas is a simple, portable, high-performance persistent store for C++ using "pointer swizzling at page fault time" to translate persistent addresses to hardware-supported virtual addresses. Texas is built on top of a normal virtual memory, and relies on the underlying virtual memory system for caching. Texas is easy to use, and is implemented as a UNIX library. It is small and can be linked into applications. It requires no special operating system privileges, and persistence is orthogonal to type---objects may be allocated on either a conventional transient heap, or on the persistent heap, as desired. Texas supports simple checkpointing of heap data. references: ftp pub/garbage/*.ps from cs.utexas.edu announcements: send mail to oops@cs.utexas.edu discussion: ? bugs: ? requires: ? ports: SunOS, Ultrix, Sun CC, GNU C++ restrictions: ? author: ? contact: oops@cs.utexas.edu how to get: ftp pub/garbage/texas/? from cs.utexas.edu updated: ? name: Triton Object-Oriented Database System version: 1.1 interfaces: E, an Ada language binding. access methods: uses Exodus robustness: The support provided for Triton is limited. As resources permit, reported bugs will be fixed. Triton is reasonably robust and has been in daily use in Arcadia for several years primarily supporting APPL/A and Amadeus. description: Triton is an object-oriented database management system designed to support the Arcadia software engineering environment. It can be used as a general purpose DBMS, although it has specialized features to support the software process capabilities in Arcadia in the form of the APPL/A language. Triton provides for multi-language access and sharing of data, dynamic creation of classes (with methods) and objects, special support for relations, and special support for triggers. Triton uses a client-server architecture with data and methods held in the server. Triton is written in E, which is a persistent C++. What Triton adds to Exodus is another interface and a lot of higher-level functionality. This includes an Object Manager shell (catalog, trigger manager, and application objects); multi-language access and sharing; dynamic definition of schema and classes; schema catalog; and triggers before and/or after method invocations. references: http://www.ics.uci.edu/Arcadia requires: Exodus/E, DLD-3.2.3, Q 2.2, Arpc401.3a restrictions: GNU General Public License [I presume --ed] author: University of Colorado Arcadia Project. contact: Dennis Heimbigner how to get: ftp pub/cs/distribs/arcadia/? from ftp.cs.colorado.edu www: http://www.cs.colorado.edu/homes/arcadia/public_html/triton.html updated: ? name: William's Object Oriented Database (Wood) version: 0.6 interfaces: MCL 2.0 access methods: custom multiuser: no transactions: no distributed: no query language: none. Has BTrees for indexing. limits: Will slow down when the database size exceeds 256 megabytes. Otherwise, database size limited by disk size (up to Macintosh limit, which is, I believe, 4 gigabytes). Object size limited to 24 megabytes. If you think of a Wood database as a random access FASL file, you'll have the right idea. robustness: Until it has a real logging/recovery mechanism, I wouldn't advise using it for mission critical data. Caches pages in memory, so if you crash, you will lose. Has a function to flush the cache to disk, so you can do explicit checkpoints to make it more robust. description: Wood is a simple persistent store for MCL 2.0. This is still alpha software. It is incomplete: though you can save/restore all Lisp objects to/from a file, there is no transaction/recovery manager and no garbage collector for the persistent heap. I will not be able to provide much support, but you get source code. discussion: info-wood-request@cambridge.apple.com bugs: bug-wood@cambridge.apple.com ports: Macintosh CommonLisp 2.0 author: Bill St. Clair how to get: ftp pub/mcl2/contrib/wood* from cambridge.apple.com updated: 1993/03/07 name: YOODA (Yet another Object Oriented Database) version: 1.2 interfaces: C++ access methods: B+Tree multiuser: yes, client-server transactions: yes, but not yet nested. distributed: yes, you can distribute a database across multiple servers. Distributed access are completly transparent. User only specifies server when he creates an object. A Two phase commit mechanism is used to handle distributed commit. query language: C++ limits: 2 GB per volume, up to 256 volumes Memory mapping limits the total size of the objects accessed in a transactions (about 2 GB) robustness: beta software but pretty stable description YOODA is a small and simple Object Oriented Database. You can use it as a persistent C++ with transaction facilities in multi-clients/multi-server architecture. It uses virtual-memory mapping techniques. The key features of YOODA are: - A distributed database with multi-clients/multi-servers architecture. - CORBA like interface for communication. - Use of memory-mapping techniques - Transparent C++ interface through the use of a precompiler - Small size of the code (< 15000 lines). - Good performances - Good management of long objects status: actively developed announcements: comp.databases.object, send mail to ea@apic.fr discussion: send mail to ea@apic.fr bugs: send mail to ea@apic.fr requires: Unix, g++ 2.5.8 or later ports: SunOs 4.1.3, Alpha-OSF1 comming soon : HP-PA HP-Ux, Solaris 2.3, NextStep 3.0 restrictions: GNU Library General Public author: Eric Abecassis ea@apic.fr contact: author how to get: ftp pub/database/yooda from ftp.uu.net ftp pub/Unix/Database from ftp.fdn.fr updated: 1994/11/14 --------------------------------------------------------------------------- --------------------------- deductive databases --------------------------- --------------------------------------------------------------------------- name: Aditi Deductive Database System version: beta release interfaces: motif, command line, NU-Prolog access methods: Base relations contain variable sized records. Base relations can be indexed with B-trees or multi-level signature files (superimposed code words) allowing multi-attribute indexing and querying, or they can be stored as unindexed flat files. multiuser: yes transactions: next release distributed: ? query language: prolog, graphical (Motif) limits: ? robustness: ? description: Aditi is a multi-user deductive database system. It supports base relations defined by facts (relations in the sense of relational databases) and derived relations defined by rules that specify how to compute new information from old information. The old information can be from derived relations as well as base relations; the rules of derived relations may be recursive. Both base relations and the rules defining derived relations are stored on disk and are accessed as required during query evaluation. ports: SPARC/SunOS, MIPS/IRIX author: The development of the Aditi system started in 1988 by Professor Kotagiri Ramamohanarao, and many people have been involved in its development, in particular Jayen Vaghani, Tim Leask, Peter Stuckey, John Shepherd, Zoltan Somogyi, James Harland and David Kemp. The support of Kim Marriott, David Keegel, and Warwick Harvey is also acknowledged. contact: aditi@cs.mu.oz.au how to get: send email to aditi@cs.mu.oz.au updated: 1992/12/17 name: ConceptBase version: V3.3 interfaces: Prolog, C, C++ access methods: TELL and ASK multiuser: yes transactions: primitive (no concurrency) distributed: no (but can be extended to do so) query language: CBQL ("query classes") limits: system is rather slow for objects bases larger than 10000 objects robustness: used by 100+ institutes, thereby quite robust description: ConceptBase is a deductive object base manager, i.e., it combines object-oriented principles with logical deduction. references: see WorldWideWeb entry: bugs: CB@picasso.informatik.rwth-aachen.de ports: SunOS 4.1.3, Solaris 2.3 (both on SunSPARC) restrictions: ConceptBase is distributed by "contact", only. It is not public domain. The source agreeement prohibits commercial and military use. author: ConceptBase Team contact: ConceptBase Team, c/o Manfred Jeusfeld, RWTH Aachen, Informatik V, Ahornstr. 55, 52056 Aachen, Germany how to get: ftp /pub/CB from ftp.informatik.rwth-aachen.de updated: 1994/06/08 name: CORAL version: 0.1 (Version 1.0 expected shortly) interfaces: Exodus storage mangager, C++ access methods: Hash-based and B+ tree indices multiuser: When used with Exodus transactions: When used with Exodus distributed: ? query language: Prolog-like with SQL-style extensions; C++ interface limits: No type checking; only atomic values in persistent relations robustness: Research software; used for teaching and in research projects, but some bugs remain description: The CORAL deductive database/logic programming system was developed at the University of Wisconsin-Madison. The CORAL declarative language is based on Horn-clause rules with extensions like SQL's group-by and aggregation operators, and uses a Prolog-like syntax. Many evaluation techniques are supported, including bottom-up fixpoint evaluation and top-down backtracking. Disk-resident data is supported via an interface to the Exodus storage manager; however, CORAL can run without Exodus if disk-resident relations are not required. A good interface to C++ is provided. Relations defined using the declarative language can be manipulated from C++ code, and relations defined using C++ code can be used in declarative rules. C++ code defining relations can be incrementally loaded. requires: AT&T C++ 2.0 or later ports: Decstations, Sun 4, Sparc, HP Snakes author: The CORAL group consists of R. Ramakrishnan, P. Seshadri, D. Srivastava and S. Sudarshan. The following people made important contributions: T. Arora, P. Bothner, V. Karra and W.G. Roth. Several other people were also involved: J. Albert, T. Ball, L. Chan, M. Das, S. Goyal, R. Netzer and S. Sterner. contact: Raghu Ramakrishnan how to get: ftp from ftp.cs.wisc.edu updated: 1993/02/12 name: MOOD5 (Material's Object-Oriented Database) version: 1.0 interfaces: Virtually none. access methods: ? multiuser: no transactions: no distributed: no query language: Query-by-example object retrieval + some limits: The database is memory resident when in use and cannot exceed 16MB. robustness: Operation is fairly stable but by no means for mission-critical data. Mostly useful for experimentation. description: MOOD5 is an object-oriented database system written in Prolog. Unlike other general purpose OODBS, the system is meant to be used by non-programmer end-users with its unified user interface named the Object-Editor, or OE, in short. Therefore, the program may better be described as an OODB application. It is developed for the purpose of exprimenting the power of OODB in dealing with complex material data. As a result, it contains may novel features which are considered to be necessary to support material database practice such as the reasoning for data retrieval, the support of literal expressions for physical quantities, and so on. Interest from engineers/scientists who are to deal with a bulk of experimental data (not only from materials) and programmers in association with them are very much appreciated. announcements: comp.databases.object, sci.materials discussion: author bugs: author ports: IBM/NEC-PC/MS-DOS author: Noboru Ono how to get: ftp pub/mood from mood.mech.tohoku.ac.jp usa: ftp pub/database/mood from ftp.uu.net uk: ftp pub/computing/databases/mood from src.doc.ic.ac.uk updated: 1994/05/17 --------------------------------------------------------------------------- --------------------------- special purpose ------------------------------- --------------------------------------------------------------------------- name: GRAS (GRAph-oriented database System) version: 5.90/9 [[6.0 alpha]] interfaces: Navigational programming interfaces for C and Modula-2 access methods: tries fro database pages, static hashing within pages multiuser: Very restricted single writer/multiple reader access [[6.0: shared read/write access with locks on a per-session, transaction, or operation basis]] transactions: yes; based on backwards logs. Checkpoints allow roll-back (and roll-forward) to a previous state. distributed: no. [[6.0: Multiclient/multiserver architecture]] query language: PROGRES (PROgrammed Graph Rewriting Systems; a language released separately) limits: 2**16 nodes per database and 2**16 databases per multi-database [[6.0: 2**32 nodes]] robustness: Has been successfully used as the underlying database for a number of research prototypes and one commercial product. Guarantees recovery from (almost) all application/system crashes description: GRAS is a database system which has been designed according to the requirements resulting from software engineering applications. Software development environments are composed of tools which operate on complex, highly structured data. In order to model such data in a natural way, we have selected attributed graphs as GRAS' underlying data model. The current version has programming interfaces for Modula-2 and C and supports: - persistent attributed, directed node- and edge-labeled graphs (including long attributes and indexes) - temporary/volatile generic sets, binary relations, and lists, - graph modification triggers causing further modifications - primitives for version control comprising the capability for efficiently storing graphs as forward/backward deltas - primitives for declaring graph schemes and for incremental evaluation of derived attributes (constraints). In additon, there are tools for compressing and displaying graphs. The GRAS system may be considered to be the core of a graph oriented DBMS environment. The environment is based on a VHLL called PROGRESS. This environment supports: a syntax-directed editor for graph schemes, rewrite rules and sequences of rules; an incremental consistency checker; an incremental compiler&interpreter for PROGRESS; an enhanced graph browser references: Kiesel, Schuerr, Westfechtel: GRAS, A Graph-Oriented Database System for (Software) Engineering Applications. Proc. CASE 93, Lee, Reid, Jarzabek (eds.): Proc. CASE '93, 6th Int. Conf. on Computer-Aided Software Engineering, IEEE Computer Society Press (1993), pp 272-286. Available by ftp as TR AIB 92-44. Schuerr: PROGRES: A VHL-Language Based on Graph Grammars, in Proc. 4th Int. Workshop on Graph-Grammars and Their Application to Computer Science, LNCS 532, Springer- Verlag 1991, pp 641-659. Available by ftp asTR AIB 90-16. announcements: a list is forming; send mail to the contact (below) bugs: use the included "send-pr" program to send bug reports requires: Modula-2, C ports: Sun-4, porting requires Modula-2 restrictions: GNU General Public License author: Lehrstuhl fuer Informatik III, RWTH Aachen, Ahornstr. 55 D-52074 Aachen, Germany. contact: (v5.x & PROGRES) Dr. Andy Sch"urr (v6.x) Norbert Kiesel how to get: (v5.x) ftp pub/unix/GRAS from ftp.informatik.rwth-aachen.de (PROGRES sun4) ftp pub/unix/PROGRES from ftp.informatik.rwth-aachen.de (PROGRES source) send mail to contact (references) ftp pub/reports/* from ftp.informatik.rwth-aachen.de (v6.x) contact Norbert Kiesel updated: 1993/11/01 --------------------------------------------------------------------------- --------------------------- flat files ------------------------------------ --------------------------------------------------------------------------- name: AddressManager version: 0.1 interfaces: Tcl/Tk multiuser: no transactions: no distributed: no query language: none limits: ? robustness: ? description: A graphical rolodex requires: wish author: Chunping Ding how to get: ftp pub/addressManager.tar.gz from banff.cssip.edu.au usa: ftp pub/tcl/code/addressManager.* from harbor.ecn.purdue.edu updated: 1994/05/12 name: EDB, the Emacs database version: 1.19 interfaces: Emacs, Emacs Lisp multiuser: no transactions: no distributed: no query language: Emacs Lisp limits: same as for Emacs -- typically 8 or 32 MB robustness: fairly high -- currently being used for mission-critical data description: EDB provides simple database access in a "user-friendly" Emacs environment for flat files. Extensions for linking records and relational-like operations exist, and further extensions are easy to make. EDB is documented by a 110-page manual, complete with indices discussion: edb-list-request@theory.lcs.mit.edu bugs: mernst@theory.lcs.mit.edu or edb-list@theory.lcs.mit.edu requires: GNU Emacs 18, GNU Emacs 19, or Lucid Emacs ports: any computer that runs Emacs -- that is, almost any computer restrictions: GNU Public License author: Michael Ernst how to get: ftp pub/emacs/edb/edb-*.tar.gz from theory.lcs.mit.edu updated: 1994/11/15 name: grok (Graphical Resource Organizer Kit) version: 1.1 interfaces: query language, GUI, GUI builder access methods: ? multiuser: no transactions: no distributed: no query language: custom limits: ? robustness: one user recommends against use as a payroll database description: Grok is a simple database manager and UI builder that can keep phone lists; store phone call logs; store todo lists; and manage any other database after simple GUI-driven customization. More precisely, grok is a program for displaying and editing strings arranged in a grid of rows and columns. Each row is presented as a "card" consisting of multiple columns, or "fields", that allow data entry. The presentation of the data is programmable; a user interface builder that allows the user to arrange fields on a card graphically is part of grok. Grok also supports a simple language that allows sophisticated queries and data retrieval. ports: IRIX, HP-UX, AIX. restrictions: ? author: Thomas Driemeyer how to get: ftp programs/X/grok* from swedishchef.lerc.nasa.gov ftp pub/unix/graphics/grok from ftp.fu-berlin.de updated: 1994/11/17 name: Jinx version: 2.1 interfaces: perl, shell multiuser: no transactions: no distributed: no query language: none limits: no limits robustness: No bugs have ever been reported description: Very easy to use, curses based flat file handler. In Perl, so no limits. Allows Join, Project, Sort etc. Representation in 2 readable unix files. A documented Perl library makes it easy to add applications. references: Online help and a 17 page tutorial. requires: Perl, cterm (distributed with jinx) ports: any unix system with ordinary perl and curses restrictions: Copyleft author: Henk Penning, Utrecht University contact: Henk Penning how to get: ftp pub/PERL/jinx.shar.Z and pub/PERL/cterm.shar.Z from ftp.cs.ruu.nl updated: 1991/11/01 name: rdb version: 2.5k interfaces: perl, shell, UNIX tools access methods: binary search, linear scan multiuser: restricted single writer/multiple reader access transactions: no distributed: no query language: none limits: no limits robustness: Is being used on many research projects; no known bugs. description: RDB is a fast, portable, Relational DataBase Management System that works with relational data in ascii files. RDB is a set of Perl modules working as filters, like "row", "column" & "join" ; a very nifty table formatting script is in "ptbl", which can do long field folding into multiple lines per row. Also includes a general report generation capability. references: Included documentation; Each module has online help. announcements: comp.lang.perl; also author email list of current users. discussion: author ports: any unix system (or other OS with redirection of I/O). author: Walt Hobbs how to get: ftp pub/RDB-hobbs/RDB-2.5j.tar.Z from rand.org updated: 1994/06/20 --------------------------------------------------------------------------- ----------------- dbm and other and raw access methods ------------------- --------------------------------------------------------------------------- name: The Berkeley DB code version: 1.85 interfaces: ndbm, hsearch access methods: hash, b+tree, recno multiuser: no transactions: no distributed: no query language: none limits: can handle large items robustness: The db routines are used in some production code so they are likely to work reasonably well. description: The Berkeley DB Code is a unification of several previous interfaces. It also forms the basis of a unified interface to new access methods (b+tree, recno). references: "A New Hashing Package for UNIX", Margo Seltzer, Ozan Yigit, Proceedings of the Winter USENIX Conference, Dallas, TX, 1991. Also available by ftp'ing pub/oz/hash.ps.Z from nexus.yorku.ca. "Document Processing in a Relational Database System, Michael Stonebraker," Heidi Stettner, Joseph Kalash, Antonin Guttman, Nadene Lynn, Memorandum No. UCB/ERL M82/32, May 1982. "LIBTP: Portable, Modular Transactions for UNIX," Margo Seltzer, Michael Olson, Proceedings 1992 Winter Usenix Conference, San Francisco, CA, January 1992. reported bugs: does not align data in memory [fixed? --ed] ports: SunOS 4.1.2, Ultrix 4.2A, BSD 4.4, and most other Unix author: Margo Seltzer, Keith Bostic, Ozan Yigit contact: Keith Bostic how to get: ftp ucb/4bsd/db.tar.gz from ftp.cs.berkeley.edu updated: 1994/09/01 name: Btree Library version: first public release interfaces: raw C library access methods: b-tree multiuser: no transactions: no distributed: no query language: none limits: values are limited to 4 bytes (long enough for a pointer!) robustness: ? description: Ths is a library that maintains a simple balanced btree index. Nothing more is provided than routines to insert, set, find (specific, next, and previous), and delete keys. Each key, however, has a spare long value that can be used to contain an offset to a data file. A library to handle fixed-length records based on these pointers should be trivial. (Can you say 'dBASEIII'?) Another failing of this library is its total inability to cope with having several programs modifying indices at the same time. (it *CAN*, but I won't vouch for the result) The good solutions to that particular problem are OS dependent, unfortunately, and I am not a database guru anyhow. ports: Unix author: Marcus J. Ranum how to get: get btree and bt-rio from comp.sources.misc volume 3 updated: 1988/06/02 name: B+tree Library version: first public release interfaces: raw C library, dbm-like library access methods: b+tree multiuser: no transactions: no distributed: no query language: none limits: ? robustness: ? description: This is the source code for a variable-length key variable page size b+tree library. Also included is source for a variety of test programs, a semi-useable record manager, and a dbm-lookalike library built on top of the record manager and b+tree. (dbm(3) will blow it away performance-wise, of course). ports: Pyramid, Sun, BSD4.3, Ultrix. Does not work on Xenix author: Marcus J. Ranum how to get: get b+tree_mgr from comp.sources.misc volume 10 updated: 1988/06/02 name: cbase version: 102 interfaces: C access methods: ISAM multiuser: no transactions: ? distributed: no query language: none limits: ? robustness: ? description: A database library (ISAM like). ports: MS-DOS restrictions: ? contact: ? how to get: ftp pub3c/SimTel/msdos/c/cbase102.zip from ftp.ibp.fr updated: ? name: dbc3 version: 1.0 interfaces: raw C library access methods: ? multiuser: no transactions: ? distributed: no query language: none limits: ? robustness: ? description: Dbclib provides a basic C interface to the database files used by dBase III. It provides funtions to both read and write them. The author is German and so all the comments are in German. It's very small (95k). [I'm not sure I have the name correct --ed] ports: Unix, MS-DOS author: D.Schanz how to get: uucp (host gold, login nuucp, no password, phone 08106-34593) /home/public/unxhigh/unix1/dbclib.tgz; or ftp pub/pc/dos/programming/c/dbclib.tar.gz from ftp.uni-kl.de updated: 1988/09/13 name: dbz version: "20 Feb 1993 Performance Release of C News" interfaces: dbm-like, command-line access access methods: hash multiuser: no transactions: no distributed: no query language: none limits: lines are limited to 1024 bytes unless the -l option is used robustness: very robust within its domain description: A dbm-like library maintained for use with C-news. ports: everything that runs C-news (lots) author: Jon Zeeff , David Butler, Mark Moraes, Henry Spencer. Hashing function by Peter Honeyman. contact: Henry Spencer how to get: included in the C-news distribution as ./dbz updated: 1992/02/11 name: gdbm version: 1.7.3 interfaces: dbm, ndbm, gdbm access methods: hash multiuser: no, but does lock the entire file transactions: no distributed: no query language: none limits: can handle large items robustness: [should be good --ed] description: An ndbm work-alike from the Free Software Foundation bugs: gnu.utils.bug author: Philip A. Nelson how to get: ftp gdbm-*.tar.gz from any gnu archive updated: 1994/05/18 name: HDS (Hierarchical Data System) version: ? interfaces: Fortran, C? access methods: ? multiuser: ? transactions: ? distributed: no query language: ? limits: ? robustness: ? description: [This is probably just a library, but it may be a full database --ed] A library for storing large multi-dimensional arrays where efficiency of access is a requirement. It is presently used in astronomy, for storing (in particular) images, spectra and time series. references: http://star-www.rl.ac.uk/ ports: Alpha OSF/1, Sparc SunOS, Sparc Solaris restrictions: ? contact: ? mdl@star.rl.ac.uk ? how to get: ftp pub/doc/star-docs/sun92.tex from starlink-ftp.rl.ac.uk updated: ? name: IDBM (ISAM Database Manager) version: 0.2.0 interfaces: C library, curses query facility access methods: ISAM multiuser: no transactions: no ? distributed: no query language: none limits: ? robustness: beta release description: IDBM is a fairly complete ISAM database system. It includes a database library, a schema compiler, a database consistaency checker, import and export routines, and curses programs to modify the database schema and the data in the database. references: ? announcements: ? discussion: ? bugs: ? requires: ? ports: Xenix, SysV, HP-UX, AIX, Amiga, SunOS, BSD, and Ultrix restrictions: May not be used for commercial purposes. author: John F Haugh II contact: ? how to get: ftp pub/idbm/idbm-0.2.x/* from ftp.nevada.edu updated: 1992/03/31 name: sdbm version: ? interfaces: ndbm access methods: hash multiuser: no transactions: no distributed: no query language: none limits: ? robustness: [I know of no problems --ed] description: ndbm work-alike hashed database library based on Per-Aake Larson's Dynamic Hashing algorithms. author: Ozan S. Yigit how to get: included in the X11R5 distribution as contrib/util/sdbm updated: 1990/03/01 name: tdbm version: 1.2 interfaces: dbm-like access methods: hashing multiuser: In theory, but the required threads package is not currently distributed. transactions: yes distributed: yes query language: none limits: Some minor ones. robustness: Probably pretty reliable, but no hard data available. description: Tdbm is a transaction processing database with a dbm-like interface. It provides nested atomic transactions, volatile and persistent databases, and support for very large objects and distributed operation. references: A paper appearing in the Summer '92 USENIX proceedings describes the design and implementation of tdbm and examines its performance. discussion: Contact the author. bugs: Contact the author. author: Barry Brachman requires: Nothing special. ports: Sparc, MIPS, AIX. Thought to be quite portable. restrictions: Copyrighted with liberal use policy. how to get: ftp pub/local/src/tdbm-1.2.tar.gz from ftp.cs.ubc.ca updated: 1994/07/06 name: Wb version: 1a2 interfaces: scheme library access method: b-tree multiuser: no transactions: no distributed: no query language: none limits: keys and data must be less that 256 bytes. Total database must be < blocksize*2^32. robustness: unknown. New release by a good programmer. description: WB is a disk based, sorted associative array C library. These associative arrays consist of variable length (less that 256 bytes) keys and values. WB comes with an interface to the Scheme implementation SCM. author: Aubrey Jaffer requires: SCM and SLIB (also available from altdorf.ai.mit.edu) ports: ? how to get: ftp archive/scm/wb1a2.tar.z from altdorf.ai.mit.edu updated: 1993/11/05 name: YACL (Yet Another Class Library) version: ? interfaces: C++ library access methods: variable-length record management, b-trees. multiuser: no transactions: no distributed: no query language: none limits: ? robustness: ? description: YACL is a general-purpose C++ class library. It happens to include some disk access methods. ports: MS Windows, Linux restrictions: Commercial use prohibited. author: M. A. Sridhar how to get: ftp pub/sridhar/yacl.zip from ftp.cs.scarolina.edu updated: 1994/05/25 --------------------------------------------------------------------------- --------------------------- full text ------------------------------------- --------------------------------------------------------------------------- name: Essence version: 1.1 interfaces: ? access methods: ? query language: ? index size: ? limits: ? robustness: ? description: Essence is a resource discovery system based on customized information extraction. Essence can produce a compact, yet representative index for large amounts of diverse information, then export the it via WAIS. discussion: send 'subscribe essence-users' to essence-users-request@cs.colorado.edu author: Darren R. Hardy , Michael F. Schwartz how to get: ftp pub/cs/distribs/essence from ftp.cs.colorado.edu updated: 1993/12/21 name: FFW version: 1.01 interfaces: command line -- intended for CGI scripts access methods: inverted index ? query language: formal expression grammar with AND, OR, NOT and (). index size: 30-50% of data size limits: ? robustness: ? description: Freetext search For Web (FFW) s a package made to provide easy-to-use freetext searching facilities over HTML documents (and as a special case plain text documents). The output is intended as input to scripts providing the user interface, typically CGI scripts. FFW is basically intended to replace similar solutions based on the Wais search engine, and solves some of the problems we experienced when using the Wais engine. FFW supports HTML. It parses input files, ignoring HTML directives and translating HTML special characters into ISO8859-1 equivalents. FFW can build indexes incrementally and can search multiple indexes at the same time. Program messages are separated in one file for easy nationalisation. Norwegian and English versions are provided. references: http://www.nta.no/produkter/ffw/ffw.html requires: g++ 2.6.2 exactly, g++ library ports: SunOS 4.1.3 author: Ken Ronny Schouten, Haiyan Yang, Berd Hefjeld: MultiTorg project at TeleNor Research, Norway. contact: ffw@nta.no how to get: ftp pub/ffw/ from ftp.nta.no updated: 1995/01/09 name: glimpse version: 1.0 interfaces: command line access methods: ? query language: logical conjunctions in command line searches index size: 2-4% limits: does not work well with source text larger than 500MB robustness: ? description: Glimpse is a text pre-scanning and query tool. It builds a database of which files a word is used in. When you want to search for a word, it knows ahead of time where it needs to look. This allows it to give very quick results without storing a large inverted index. references: U. Manber and S. Wu, "GLIMPSE: A Tool to Search Through Entire File Systems," Usenix Winter 1994 Technical Conference, San Francisco (January 1994), pp. 23-32. Also, Technical Report #TR 93-34, Dept. of Computer Science, University of Arizona, October 1993 (a postscript file is available by anonymous ftp at cs.arizona.edu:reports/1993/TR93-34.ps). S. Wu and U. Manber, "Fast Text Searching Allowing Errors," Communications of the ACM 35 (October 1992), pp. 83-91. discussion: glimpse-request@cs.arizona.edu ports: portable, binaries provided for sun, mips, linux and alpha author: Udi Manber, Sun Wu, and Burra Gopal, Department of Computer Science, University of Arizona. contact: glimpse@cs.arizona.edu how to get: ftp glimpse/* from cs.arizona.edu updated: 1994/04/27 name: Liam Quin's text retrieval package (lq-text) version: 1.13 interfaces: command line, curses access methods: hash (dbm) plus clustered linked list multiuser: read only distributed: no, can be used over nfs if the systems are similar query language: very limited command line limits: 30-bit max document size, 31-bit distinct words in vocabulary, up to 2^24 documents (possibly more but I don't have enough disk to test anything like that!) index size: >30%, <100% of input text robustness: The README says that there are bugs. description: lq-text is a text retrieval package. That means you can tell it about lots of files, and later you can ask it questions about them. The questions have to be: "which files contain this word?" or "which files contain this phrase?", but this information turns out to be rather useful. Lqtext has been designed to be reasonably fast. It uses an inverted index, which is simply a kind of database. This tends to be smaller than the size of the data, but more than half as large. You still need to keep the original data. Lqtext uses dbm (berkeley db or sdbm) to store its indexes. discussion: lq-text-beta-request@sq.com bugs: lq-text-beta@sq.com ports: most version of unix (except SCO) restrictions: permission required for commercial use. author: Liam R. E. Quin how to get: ftp pub/lq-text*.tar.Z from relay.cs.toronto.edu updated: 1993/12/10 name: mg version: 1.0 interfaces: command line interpreter, X (tcl) access methods: ? multiuser: no transactions: no distributed: no query language: boolean and ranked queries using cosine similarity measure index size: 5-15% of text being indexed, depending on document size and richness of vocabulary. Text is also stored compressed, requires around 25-30% of original size. Complete retrieval system requires 30-45% of original text size. limits: Will probably fail when used with > 4Gb robustness: It is a research prototype, and as such there are no guarantees. Don't rely on it as a primary archive tool; but it is very useful as an adjunct to other storage mechanisms for e.g. maintaining a personal mail retrieval system. And, of course, for research purposes. description: mg compresses and indexes documents and images (indexed by user-supplied textual description). All components are stored compressed: text by a word-based method that reduces the space requiremnent to around 25% of input; images by one of three different methods (FELICS, Textual Image Compression, two-level image compression); and index using index compression methods. The package also includes a mechanism for fast and economical creation of the index in thge first place. It requires about 8 hours (Sun SPARC 10 Model 512) to compress and index 2 Gb of text (the TREC collection); final retrieval system requires about 700 Mb to operate. Multi-term Boolean and ranked queries are answered within seconds. references: "Managing gigabytes: compressing and indexing documents and images", Witten, Moffat, and Bell, Van Nostrand Reinhold, 1994, ISBN 0-442-01863-0. "Compression and fast indexing for multi-gigabyte text databases", Moffat and Zobel, Australian Computer Journal, 26(1):1-9, February 1994. status: actively-develped research prototype. Support of public use is not a priority. ports: SunOS, Solaris, SGI, Ultrix, NeXT. restrictions: GNU General Public License author: Tim Bell , Stuart Inglis , Alistair Moffat , Neil Sharman , Tim Shimmin , Ian Witten , Justin Zobel , and others. contact: Alistair Moffat how to get: ftp pub/mg from munnari.oz.au updated: 1994/03 name: qt (Query Text) version: 0.1 interfaces: unix command line access methods: ? multiuser: no distributed: no query language: unix command line index size: ? limits: ? robustness: ? description: Qt creates, maintains, and queries a full text database. The database file system is organized as an inverted index. The program is written as a single script, in Bourne Shell, and permits simple natural language queries. [qt appears to be easier to use than lq-text and wais --ed] bugs: author ports: Unix, SysV.4, AIX, OSF/1, etc. author: John Conover how to get: comp.sources.unix volume 27 updated: 1993/10/18 name: SMART version: 11.0 interfaces: terminal, X (slightly oder version), and several under development including Z39.50 access methods: inverted file search or sequential search multiuser: yes, but last writer wins when there are update conflicts distributed: In-house version, to be made public in fall query language: Natural language index size: approx 40% of original text. limits: Can only handle roughly 4 Gbytes of text in non-distributed version. robustness: Research tool; parts have been well-tested but others not. description: SMART is an implementation of the vector-space model of information retrieval proposed by Salton back in the 60's. The primary purpose of SMART is to provide a framework in which to conduct information retrieval research. Standard versions of indexing, retrieval, and evaluation are provided. The system is designed to be used for small to medium scale collections, and offers reasonable speed and support for these actual applications. SMART analyses the collection of information and builds indexes. It can then be used to build natural-language based information retrieval software. It uses feedback from the user to tighten its search. references: Z39.50 URL: restrictions: Research use only. discussion: smart-people-request@cs.cornell.edu ports: Unix (works under Linux, does not work under Ultrix, ?) contact: how to get: ftp pub/smart/* from ftp.cs.cornell.edu updated: 1992/07/21 name: WAIS (Wide Area Information Server) version: 8 b5.1 interfaces: the wais protocol (Z39.50) access methods: inverted string index multiuser: read only distributed: client/server query language: natural language, boolean, Relevance Feedback index size: roughtly = data size limits: "none" robustness: fairly high description: There are three main components: WAISINDEX, WAISSERVER, and WAISSEARCH. WAISINDEX creates an inverted file index. WAISINDEX includes filters for a number of common file formats. WAISSERVER listens for Z39.50 packets and tries to answer them. WAISSEARCH is the user agent that talks to WAISSERVERs. There are several front ends: shell, X, and emacs. announcements: wais-interest-request@think.com discussion: wais-discussion-request@think.com ports: vax, sun-3, sun-4, NeXT, sysV restriction: commercial version exists, contact info@wais.com author: Harry Morris , Brewster Kahle , Jonny Goldman how to get: ftp pub/freeware/unix-src/* from wais.com updated: 1992/11/16 --------------------------------------------------------------------------- --------------------------- interfaces ------------------------------------ --------------------------------------------------------------------------- name: AdaSAGE version: ? interfaces: SQL, embedded SQL. transactions: yes distributed: ? query language: SQL robustness: ? description: AdaSAGE is not a DBMS. AdaSAGE is an application development tool that provides facilities for creating an application specific relational data base. There are two aspects of SQL dialog to consider. First is listening to SQL and responding by executing the requested command. Second is issuing SQL to get a foreign system to execute some process on your behalf. In the first case AdaSAGE provides both an embedded SQL technology and an interactive SQL system adapted to comply with ANSI-SQL DML Level 1. In the second case AdaSAGE does not provide any capabilities for creating SQL commands, but since AdaSAGE is a set of Ada packages there is no reason that a package could not be developed to do so. The capability to record all transactions and roll forward from previous dates gives an audit trail and recover capability. These features are often provided within data base management systems, and are provided with AdaSAGE as a logging option, but seldom if ever are they used in final applications because of the excessive time and data storage requirements. references: ? announcements: ? discussion: ? bugs: ? requires: Ada ports: MS-DOS, UNIX restrictions: Use restricted to US DoD, DoE and educational institutions. contact: ? how to get: ftp pub/sage/* from navair1.inel.gov updated: ? name: CB++ version: 0.1 interface from: C/C++ interface to: SunOS/Oracle (DOS+Windows/Oracle,Gupta, OS/2 Sybase) description: CB++ provides a plain C/C++ interface (not embedded) for SQL database server access. It was written in 1989 as a basis for storing C++ objects in a relational database. It is very simple to use and makes applications portable among different SQL databases. The library itself is relatively easy to port as the database vendor specific code is separated into a single C++ class which makes up only a limited part of the library. The author supports the current SunOS/Oracle version and server ports to other UNIX databases (DOS-, Windows-, OS/2-stuff is provided as it is and no longer supported) requires: C++ ports: Oracle 6 for SunOS 4.1.3, Gupta SQL Server for DOS/MS-Windows, OS/2 SQL Server author: Bernhard Strassl how to get: ftp R5contrib/CB++.0.1.tar.Z from ftp.x.org updated: 1993/10/05 name: ciORA version: alpha interface from: C interface to: Oracle query language: ? robustness: ? description: ciORA is a set of C interface routines to Oracle that are modeled after the standard I/O portion of the C library. ciORA presents a familiar interface to an experienced C programmer by avoiding the awkward embedding of SQL statements using precompilers and the tedium of using low-level OCI calls. ciORA eliminates the need for precompilers by supplying an interface library providing equivalent functions. It also provides a higher level of abstraction to the functions in the Oracle Call Interface (OCI). ciORA manages (and hides) the tedious details necessary when writing programs using OCI by replacing the cumbersome Oracle constructs such as logon data areas, cursor data areas, and external datatypes, the Oracle array interface, bind variables, select-list-items, and the like with constructs familiar to a C programmer using the standard I/O portion of the C library. ciORA also provides a consistent interface to Oracle errors similar to the convention used in C's errno. requires: Oracle ports: IRIX 5.2, Oracle 7.0.15.4.0 restrictions: GNU General Public License author: Zane Dodson how to get: email author updated: 1994/09/10 name: cisamperl version: 0.9 interface from: perl interface to: Informix C-ISAM 3.1 library limits: ? robustness: ? description: cisamperl/rocisperl is a package, which implements an interface to the INFORMIX C-ISAM library for perl. It is coded as an usub (see perl documentation) and needs to be compiled with perl and the C-ISAM library to form 2 separate executables called cisamperl and rocisperl respectively. cisamperl is a fully functioning (unless I forgot something) perl executable with calls for C-ISAM file access added. rocisperl is the same, with all calls that create/modify/delete C-ISAM files or records disabled. requires: C-ISAM 3.1, perl4 ports: ? author: Mathias Koerber how to get: ftp pub/perl/db/perl4/cisamperl/cisamperl-* from ftp.demon.co.uk updated: 1994/10/29 name: ctreeperl version: ? interface from: perl interface to: FairCom Ctree description: A perl interface for FairCom Ctree file indexing. requires: Ctree author: John Conover how to get: ftp pub/perl/db/ctreeperl from ftp.demon.co.uk updated: 1994/04/07 name: dbf (xbase manipulation package) version: ? interface from: command line interface to: xbase files access methods: ? multiuser: no transactions: no distributed: no query language: none limits: ? robustness: ? description: DBF is a set of tools and library routines to manipulate xbase files. The tools allow xbase files to be created and manipulated from the command line. author: Brad Eacker how to get: comp.sources.misc volume 43 updated: 1994/06/27 name: dbf read routines in perl version: ? interface from: perl interface to: xbase files description: very simple (15 line) routines to read dbf files author: David Rensin how to get: ftp pub/source/read_dbf_in_perl from ftp.idiom.com updated: 1994/11/13 name: DSQL version: 3.0 interface from: Unix, Macintosh, MS-DOS, MS-Windows, and Macintosh Hypercard interface to: Unix/Informix, VMS/Oracle description: DSQL is a simple client/server protocol to support remote access of SQL databases. DSQL was designed in response to a perceived need at Genentech to provide graphical front-ends on Macintosh computers to Informix relational databases running on Unix servers. DSQL version 3 is distributed with 2 server implementations and four client library implementations. The API for the client libraries has been standardized, and the client code is divided into portable and architecture-specific portions. requires: ? ports: Mac, PC, Unix author: The Genentech Scientific Computing Technology Development group. Original authors: David Mischel, Terry Oberzeir, Scooter Morris , Kathryn Woods. Current team: Jim Fitzgerald, David Mischel, Scooter Morris, Terry Oberzier, and Dan Lamb (VMS/Oracle). contact: ? how to get: ftp pub/dsql.3.tar.Z from cgl.ucsf.edu updated: 1993/06/25 name: Ingperl version: 2.0 interface from: perl interface to: Ingres descritpion: Ingperl is a set of user subroutines to enable Perl programs to access Ingres databases. Ingperl used to be called Sqlperl. requires: Perl 3.027 or higher, ? discussion: perldb-interest-REQUEST@vix.com author: Ted Lemon how to get: ftp pub/perl/db/sqlperl/? from ftp.demon.co.uk updated: 1994/04/11 name: Isqlperl version: 1.1 interface from: perl interface to: Informix limits: Maximum concurrently open cursors configured at build time. descritpion: Isqlperl is a set of user subroutines to enable Perl programs to access Informix databases. requires: Perl 4.035 or higher, Informix ESQL/C (Online, SE, or Turbo) discussion: perldb-interest-REQUEST@vix.com restrictions: GNU Public License author: Bill Hails how to get: ftp pub/perl/db/isqlperl/isqlperl-1.1.shar.Z from ftp.demon.co.uk updated: 1993/10/02 name: Isqltcl ? version: ? interface from: tcl interface to: Informix description: Isqltcl is an extension to Tool Command Language (Tcl) that provides access to an Informix database server. Isqltcl adds additional Tcl commands that login to an Informix Server, pass SQL code, read results, etc. requires: ? discussion: comp.lang.tcl author: Srinivas Kumar how to get: ftp tcl/extensions/isqltcl.tar.Z from harbor.ecn.purdue.edu updated: 1993/09/15 name: Interperl version: ? interface from: perl interface to: Interbase descritpion: Interperl is a set of user subroutines to enable Perl programs to access Interbase databases. requires: Perl 3.027 or higher, ? discussion: perldb-interest-REQUEST@vix.com author: Buzz Moschetti how to get: ftp pub/perl/db/interperl/? from ftp.demon.co.uk updated: ? name: Onyx version: 2.34 interface from: Onyx 4gl, (emacs and smalltalk planned) interface to: Ingres89, Informix, GAWK, Shql, Yard, Minerva SQL, SqlPostgres (OBST planned) The informix port is slow and no longer being extended because the author feels their support is inadiquate. interfaces: Onyx uses a OO-Parser to access different engines The transaction manager can be accessed by any aplication which is able to use pipes or TCP/sockets. multiuser: Depends on the used engine. transactions: Yes, but no rollback, all transactions are atomic as a block, replication of transactions is planned for one of the next releases. distributed: Yes its possible to connect to any mentioned database anywhere in the net. Replication is planned. query language: SQL + Onyx 4gl (based on Model-View-Controller idea) limits: Current version uses memory to store selected data. robustness: Onyx is experimental, but useable for clients. The author is supporting himself by writing applications written in Onyx 4GL. description: Onyx is a 4gl based on the idea of model view controller. Onyx 4gl connects to a transaction manager based on a OO-Parser generator via a socket. While the design goal of the protocol was to keep it as simple as posible, its a good starting point of writing vendor independent database applications. status: experimental; actively developed and supported. announcements: comp.os.linux.announce bugs: Michael Koehne requires: BSD like system, GNU C++, a database engine (minimum GNU-AWK) ports: Tested on Linux and SunOs. restrictions: GNU Public Licence author: Michael Kraehe how to get: ftp incoming/onyx/? from ftp.germany.eu.net (every versions) ftp pub/comp/i386/Linux/Local.EUnet/Applications/Database from ftp.germany.eu.net (stable versions) updated: 1994/12/01 name: Oraperl version: ? interface from: perl interface to: Oracle descritpion: Oraperl is a set of user subroutines to enable Perl programs to access Oracle databases. requires: Perl 3.027 or higher, Oracle Pro*C discussion: perldb-interest-REQUEST@vix.com author: Kevin Stock how to get: ftp pub/perl/db/oraperl/? from ftp.demon.co.uk updated: ? name: Oratcl version: 2.2 interface from: TCL interface to: Oracle description: Oratcl is an extension to Tool Command Language (Tcl) that provides access to a Oracle Database server. Oratcl adds additional Tcl commands that login to an Oracle Server, pass SQL code, read results, etc. Oratcl was inspired by similar tools written for Perl (sybperl, oraperl) but was written from scratch instead of borrowing on the work of either Perl extension. requires: Tcl 6.7, Tk 3.2, Oracle OCI libraries 1.5, Oracle SQL Server Version 6 or Version 7 discussion: comp.lang.tcl author: Tom Poindexter how to get: ftp tcl/extensions/oratcl-2.2.tar.gz from ftp.aud.alcatel.com updated: 1994/11/04 name: pgperl version: ? interface from: perl interface to: Postgres descritpion: pgperl is a set of user subroutines to enable Perl programs to access Postgres databases. requires: Perl 3.027 or higher, ? discussion: perldb-interest-REQUEST@vix.com author: Igor Metz how to get: ftp pub/perl/db/pgperl/? from ftp.demon.co.uk updated: ? name: SIOD (Scheme In One Defun/Day) version: 3.0 interface from: C, C++, Scheme interface to: Oracle, Digital RDB, flat ascii, flat binary. access methods: flat files contain symbolic expression such as hash tables. multiuser: yes with commercial DB, no with flat files. transactions: yes with commercial DB, no with flat files. distributed: yes with commercial DB, no with flat files. query language: SQL, any SCHEME program. limits: None. robustness: ? description: This is a scheme interpreter with built-in procedures using the Oracle Call Interface (OCI) and DIGITAL RDB SQL Services. You can use it merely as a flexible database loader/unloader with fast binary flat-file data save/restore. Or you can use it to apply the classic "Symbolic Manipulation" or "Artificial Intelligence" techniques on your data sets. The main-program can be oriented towards batch, character-cell terminal, or Window/GUI. references: "Structure and Interpretation of Computer Programs" MIT Press. announcements: comp.lang.scheme, comp.databases.rdb, comp.databases.oracle bugs: Contact the author. requires: C compiler, your favorite commercial DB. ports: VMS, WINDOWS NT, UNIX, OS/2, MACINTOSH. author: George Carrette how to get: ftp pub/gjc/siod* from ftp.std.com. updated: 1994/05/01 name: Sybperl version: 1.011 patch 12 interface from: perl4 interface to: Sybase descritpion: Sybperl is a set of user subroutines to enable Perl programs to access Sybase databases. requires: Perl 3.027 or higher, ? discussion: perldb-interest-REQUEST@vix.com author: Michael Peppler how to get: ftp pub/perl/db/mod/Sybperl/ from ftp.demon.co.uk updated: 1994/12/22 name: Sybperl version: 2a7 (a is for alpha) interface from: Perl5 interface to: Sybase descritpion: Sybperl is a set of user subroutines to enable Perl programs to access Sybase databases. Sybase::DBlib implements a fairly large subset of Sybase's DBlibrary API in the Perl5 fashion (ie using some of the new OO features of Perl5) requires: perl5 discussion: perldb-interest-REQUEST@vix.com author: Michael Peppler how to get: ftp pub/perl/db/mod/Sybperl/ from ftp.demon.co.uk updated: 1994/12/22 name: Sybtcl version: 2.2 interface from: TCL interface to: Sybase description: Sybtcl is an extension to Tool Command Language (Tcl) that provides access to a Sybase Database server. Sybtcl adds additional Tcl commands that login to a SQL Server, pass SQL code, read results, etc. Sybtcl was inspired by similar tools written for Perl (sybperl, oraperl) but was written from scratch instead of borrowing on the work of either Perl extension. requires: Sybase Open Client (DB-Library), Sybase SQL Server discussion: comp.lang.tcl author: Tom Poindexter how to get: ftp tcl/extensions/sybtcl-2.2.tar.gz from ftp.aud.alcatel.com updated: 1994/11/04 name: tclgdbm version: 1.0 interface from: TCL interface to: gdbm description: none provided discussion: comp.lang.tcl author: Tuan Doan how to get: ftp pub/tcl/extensions/tclgdbm1.0* from harbor.ecn.purdue.edu updated: 1994/02/08 name: tcl+gdbm version: 0.1 interface from: TCL interface to: gdbm description: none provided discussion: comp.lang.tcl author: Christian Lindig how to get: ftp pub/local/sw/tcl+gdbm-0.1.tar.gz from ftp.ips.cs.tu-bs.de updated: 1994/05/04 name: Uniperl version: ? interface from: perl interface to: Unify 5.0 descritpion: Uniperl is a set of user subroutines to enable Perl programs to access Unify databases. requires: Perl 3.027 or higher, ? discussion: perldb-interest-REQUEST@vix.com author: Rick Wargo how to get: ftp pub/perl/db/uniperl/? from ftp.demon.co.uk updated: ? name: Willow version: 2.2 interface from: user interface to: WWW/Mosaic, Z39.50, ZDist (formerly free-WAIS) from CNIDR description: Willow (Washington Information Looker-upper Layered Over Windows) is a general purpose information retrieval tool. It provides a single, easy-to-use graphical user interface (X Windows / Motif) to any number of text-based bibliographic databases. references: http://www.cac.washington.edu/willow/home.html ports: DEC/Ultrix, Solaris, SunOS, RS6000/AIX. contact: willow@cac.washington.edu how to get: ftp willow/* from ftp.cac.washington.edu updated: 1994/06/30 --------------------------------------------------------------------------- --------------------------- other ----------------------------------------- --------------------------------------------------------------------------- name: "A Guide to the SQL standard" what: BNF SQL grammer version: ? description: A BNF grammer for SQL is included in the book. how to get: buy the book: "A Guide to the SQL standard" by Hugh Darwen and C.J. Date. updated: ? name: CDF (Common Data Format) what: data exchange library version: ? interfaces: ? access methods: ? distributed: ? query language: ? limits: ? robustness: ? description: A library and toolkit for multi-dimensional data sets. The basic component of CDF is a software programming interface that is a device independent view of the CDF data model requires: ? ports: ? restrictions: ? contact: ? how to get: ftp cdf.dir/* from nssdca.gsfc.nasa.gov. The CDF library to provide applications access to remote CDF datasets, can be obtained from its author: Hillel Steinberg . updated: ? name: examples from: "Information Retrieval, Data Structures & Algorithms," William B. Frakes, Ricardo Baeza-Yates, Editors, Prentice Hall, Englewood Cliffs, New Jersey 07632, 1992, ISBN 0-13-463837-9. what: example database code version: ? descriptions: example code from the book "Information Retrieval, Data Structures & Algorithms" how to get: ftp pub/reuse/ircode.tar.Z from ftp.vt.edu author: [resumably William B. Frakes, Ricardo Baeza-Yates] updated: ? name: _lex & yacc_ by Levine, Mason & Brown published by O'Reilly what: SQL yacc grammer version: ? parts: grammar description: In _lex & yacc_, by Levine, Mason & Brown an SQL parser is included as an example grammar author: Levine, Mason & Brown how to get: buy the book, or ftp published/oreilly/nutshell/lexyacc/? from ftp.uu.net. updated: ? name: MultiCal what: database date manipulation library version: 1.0 interfaces: ? access methods: ? multiuser: no transactions: no distributed: no query language: enhanced SQL2 limits: ? description: MultiCal is both a novel approach to supporting multiple calendars and internationalization of time constants and a query processor prototype that demonstrates this approach. MultiCal consists of about 48K source lines of C code; the query processor prototype consists of about 63K source lines of code. The documentation consists of fifteen documents, comprising some 300 pages of material. MultiCal consists of an approach to providing limited extensibility for support of multiple calendars and languages for temporal support within a database management system (DBMS). We have augmented the Structured Query Language (SQL), specifically, SQL2, with time values, i.e., temporal constants. Our approach is notable in that we allow many different calendars to be used in the database management system, and we incorporate only calendar-independent constructs into the language. We introduce three new temporal data types. New language features are defined for temporal built-in functions, special time values, arithmetic expressions involving time, temporal predicates, and aggregate functions over time. Ten languages are supported. To illustrate how an existing DBMS could be augmented to support multiple calendars, we provide a prototype DBMS that supports the proposed extensions. This prototype consists of query analysis and execution components. It eschews traditional functionality such as concurrency control and disk access methods, as these aspects are not relevant to timestamp management. ports: Sun4 contact: or Rick Snodgrass how to get: ftp tsql/multical/* from ftp.cs.arizona.edu updated: 1993/10/30 name: persist++ what: C++ object marshal/demarshal library version: 0.2 interfaces: C++ access methods: none robustness: ? description: Persist++ is a set of serialize/materialize/marshal routines that make it easy to store C++ objects to files or to send them across the network. author: Herman Moons how to get: ftp pub/impulse/persist++_0.2.tar.Z from ftp.cs.kuleuven.ac.be updated: 1994/08/16 name: SQL parser ? what: SQL yacc grammer ? version: ? description: ? author: Bruce Ring <73172.735@compuserve.com> how to get: wait for it to be posted to a comp.sources group updated: 1994/11/04 name: SQL-86 in HTML what: html version of some of the SQL-86 standard references: http://case50.ncsl.nist.gov/sql-86/ author: David Flater updated: 1994/12/30 -- ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 7608 Topton St. | New Carrollton, MD 20784 | I run Journey2 (Freebsd 2.0) and n3lxx (301) 459-2316 | (FreeBSD 1.1.5.1) and am I happy! ----------------------------+----------------------------------------------- From owner-freebsd-ports Wed Mar 22 18:48:31 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA25214 for ports-outgoing; Wed, 22 Mar 1995 18:48:31 -0800 Received: from rivers.oscs.montana.edu (rivers.oscs.montana.edu [192.31.215.70]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA25208 for ; Wed, 22 Mar 1995 18:48:29 -0800 Received: by rivers.oscs.montana.edu (5.65/DEC-Ultrix/4.3) id AA14156; Wed, 22 Mar 1995 19:47:51 -0700 Date: Wed, 22 Mar 1995 19:47:46 -0700 (MST) From: Jason Boerner To: Mitchell Ackerman <0006619934@mcimail.com> Cc: ports@FreeBSD.org Subject: Re: non-initial installation In-Reply-To: <91950322163219/0006619934PK4EM@MCIMAIL.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk I found installs from the CD to be a bit unattractive. Hence, I pull everything from the network. I like haveing source code, so I: cd /usr/ports NOTE: You may need to set the file protections levels. ftp freebsd.cdrom.com cd /pub/FreeBSD/ binary get ports.tar.gz bye gunzip ports.tar.gz cd .. tar -xvf ports/ports.tar An alternate methode is to look in the CD under packages. Find the package that you want and perform a pkg_add . This will create the ports directory on your system in it's full glory (This is really not that large). I then CD into the ports direcotry containing the stuff that I need/want to build and perform a make. ***NOTE TO SOMEONE WHO KNOWS A LOT ABOUT THESE PORT INSTALL METHODES: I believe that this not only build the files but installs (make install) them. However they do not show up with pkg_info -a. Does anyone know how to/where to fix this at? This and fixing the uemacs port are my next too little assignments. I hope that this helps. On Wed, 22 Mar 1995, Mitchell Ackerman wrote: > To whom it may concern, > > I have installed the base operating system on my PC without any of the optional > packages. The initial installation was performed using cpio.flp. What is the > method for installing additional software from CDROM at this point? > > Any suggestions whould be much appreciated, thanks, Mitchell. > > > > From owner-freebsd-ports Wed Mar 22 20:09:48 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA27984 for ports-outgoing; Wed, 22 Mar 1995 20:09:48 -0800 Received: from glueserv1.umd.edu (glueserv1.umd.edu [129.2.70.69]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA27977 for ; Wed, 22 Mar 1995 20:09:45 -0800 Received: from mocha.eng.umd.edu (mocha.eng.umd.edu [129.2.98.16]) by glueserv1.umd.edu (8.6.10/8.6.4) with ESMTP id XAA24110 for ; Wed, 22 Mar 1995 23:09:28 -0500 Received: (chuckr@localhost) by mocha.eng.umd.edu (8.6.10/8.6.4) id XAA20552; Wed, 22 Mar 1995 23:09:27 -0500 Date: Wed, 22 Mar 1995 23:09:27 -0500 (EST) From: Chuck Robey To: FreeBSD-ports@FreeBSD.org Subject: dbm code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk Whilst I was re-doing all of my tcl library stuff (for the tgdb) I was thinking about adding tcl-gdbm to the list, but I wanted to do it for FreeBSD's dbm code, I think its ndbm. I've used code like that before, but not this one; does anyone know of a tutorial or a code example of how the various and sundry functions are pasted toether in a (reasonably) sane application? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 7608 Topton St. | New Carrollton, MD 20784 | I run Journey2 (Freebsd 2.0) and n3lxx (301) 459-2316 | (FreeBSD 1.1.5.1) and am I happy! ----------------------------+----------------------------------------------- From owner-freebsd-ports Wed Mar 22 22:42:54 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA01310 for ports-outgoing; Wed, 22 Mar 1995 22:42:54 -0800 Received: from dtr.com (dtr.rain.com [204.119.8.19]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA01298 for ; Wed, 22 Mar 1995 22:42:52 -0800 From: bmk@dtr.com Received: (from bmk@localhost) by dtr.com (8.6.9/8.6.9) id WAA28535 for ports@freebsd.org; Wed, 22 Mar 1995 22:39:45 -0800 Message-Id: <199503230639.WAA28535@dtr.com> Subject: problems with inn port To: ports@FreeBSD.org Date: Wed, 22 Mar 1995 22:39:44 -0800 (PST) Reply-To: bmk@dtr.com X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 527 Sender: ports-owner@FreeBSD.org Precedence: bulk I've compiled and configured the news/inn port... When I fire up /etc/rc.news, I get the following on my syslog: Mar 22 22:29:50 everest innd: ME descriptors 128 Mar 22 22:29:50 everest innd: ME outgoing 115 Mar 22 22:29:50 everest innd: /usr/local/news/lib/history cant dbminit ME No such file or directory innd then dies without further comment. innd -s does not report any errors with my newsgroups file, and I have run makehistory. This is on a fresh news install. Anyone want to clue me in as to what I've missed? From owner-freebsd-ports Wed Mar 22 23:30:54 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA02711 for ports-outgoing; Wed, 22 Mar 1995 23:30:54 -0800 Received: from easynet.com (easyr.easynet.net [198.67.38.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA02705 for ; Wed, 22 Mar 1995 23:30:53 -0800 Received: by easynet.com (Smail3.1.28.1 #7) id m0rrhDt-000rcEC; Wed, 22 Mar 95 23:22 WET Message-Id: From: brian@mediacity.com (Brian Litzinger) Subject: Re: problems with inn port To: bmk@dtr.com Date: Wed, 22 Mar 1995 23:22:24 -0800 (PST) Cc: ports@FreeBSD.org In-Reply-To: <199503230639.WAA28535@dtr.com> from "bmk@dtr.com" at Mar 22, 95 10:39:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 913 Sender: ports-owner@FreeBSD.org Precedence: bulk > > I've compiled and configured the news/inn port... When I fire up > /etc/rc.news, I get the following on my syslog: > > Mar 22 22:29:50 everest innd: ME descriptors 128 > Mar 22 22:29:50 everest innd: ME outgoing 115 > Mar 22 22:29:50 everest innd: /usr/local/news/lib/history cant dbminit ME No > such file or directory > > innd then dies without further comment. > > innd -s does not report any errors with my newsgroups file, and I have > run makehistory. This is on a fresh news install. > > Anyone want to clue me in as to what I've missed? > Sorry, ports, mail to the author of the article bounced. I'm guessing. su to news and: /usr/lib/news/bin/makehistory if it still doesn't work after running 'makehistory'. Look in /usr/lib/news for files of the format 'history.n.*' and move them to 'history.*' (make sure the permissions stay news:news:0664) Brian Litzinger brian@easynet.com From owner-freebsd-ports Thu Mar 23 05:47:35 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA10299 for ports-outgoing; Thu, 23 Mar 1995 05:47:35 -0800 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA10292 for ; Thu, 23 Mar 1995 05:47:34 -0800 Received: (from bugs@localhost) by ns1.win.net (8.6.9/8.6.9) id IAA19191 for ports@FreeBSD.ORG; Thu, 23 Mar 1995 08:49:07 -0500 From: Mark Hittinger Message-Id: <199503231349.IAA19191@ns1.win.net> Subject: problems with inn port (fwd) To: ports@FreeBSD.org Date: Thu, 23 Mar 1995 08:49:06 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 870 Sender: ports-owner@FreeBSD.org Precedence: bulk > From: bmk@dtr.com > Subject: problems with inn port > > I've compiled and configured the news/inn port... When I fire up > /etc/rc.news, I get the following on my syslog: > Mar 22 22:29:50 everest innd: /usr/local/news/lib/history cant dbminit ME No > such file or directory > innd then dies without further comment. > Anyone want to clue me in as to what I've missed? 1. Make sure that the history file name is properly configured in your config.data 2. Make sure that you have valid files after you run makehistory. There should be three files. 3. Make sure you rename the files created by makehistory to be the ones that INN will use. 4. Make sure that the ownership/protection of the history files are correct for the "news" user. 5. Don't compile with -DMMAP. Steps 2-4 are in the INN FAQ. Good Luck, Mark Hittinger bugs@win.net From owner-freebsd-ports Thu Mar 23 11:22:33 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19025 for ports-outgoing; Thu, 23 Mar 1995 11:22:33 -0800 Received: from marmite.Stanford.EDU (2842@marmite.Stanford.EDU [36.159.0.58]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA19019 for ; Thu, 23 Mar 1995 11:22:32 -0800 Received: (hlew@localhost) by marmite.Stanford.EDU (8.6.10/8.6.4) id LAA07058; Thu, 23 Mar 1995 11:22:12 -0800 Date: Thu, 23 Mar 1995 11:22:12 -0800 (PST) From: Howard Lew To: Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?= cc: chaos@rivers.oscs.montana.edu, Ports@FreeBSD.org Subject: Re: Xpaint port... In-Reply-To: <199503220600.WAA11997@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk Well... all xpaint talk has led me to try out the package... Has anyone tried the xpaint package in the packages directory? Xpaint seems to run, but when I click a button and hold down the button to choose a menu option, I don't see a menu bar (although the pull down menu shows up). Or is my setup wrong...? I'm using XF86_S3 (version 3.1.1) under 16 bit color mode. I recompiled xpaint from the ports directory with the patches aa-ae sucessfully, but the problem is still there. Hmmm... Any ideas? Xfig works great though. Thanks guys! Howard From owner-freebsd-ports Thu Mar 23 11:44:48 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19318 for ports-outgoing; Thu, 23 Mar 1995 11:44:48 -0800 Received: from bigdipper.umd.edu (bigdipper.umd.edu [128.8.220.139]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA19310 for ; Thu, 23 Mar 1995 11:44:45 -0800 Received: (from adhir@localhost) by bigdipper.umd.edu (8.6.8/8.6.6) id OAA27144; Thu, 23 Mar 1995 14:44:16 -0500 Date: Thu, 23 Mar 1995 14:44:16 -0500 (EST) From: "Alok K. Dhir" To: bmk@dtr.com cc: ports@FreeBSD.org Subject: RTFM (was Re: problems with inn port) In-Reply-To: <199503230639.WAA28535@dtr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk On Wed, 22 Mar 1995 bmk@dtr.com wrote: > I've compiled and configured the news/inn port... When I fire up > /etc/rc.news, I get the following on my syslog: > > Mar 22 22:29:50 everest innd: ME descriptors 128 > Mar 22 22:29:50 everest innd: ME outgoing 115 > Mar 22 22:29:50 everest innd: /usr/local/news/lib/history cant dbminit ME No > such file or directory > > innd then dies without further comment. > > innd -s does not report any errors with my newsgroups file, and I have > run makehistory. This is on a fresh news install. > > Anyone want to clue me in as to what I've missed? Sure - use makehistory -f. Look at "man news.recovery" and the INN FAQ for more info. -------------------------------------___--------------------------------- | Al Dhir, Programmer Analyst /___\ UMCP Ag-Engineering Dept | | Internet: adhir@bigdipper.umd.edu (o o) (301) 405-1197 | ---------------------------------ooO-(_)-Ooo----------------------------- From owner-freebsd-ports Thu Mar 23 12:59:07 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA20674 for ports-outgoing; Thu, 23 Mar 1995 12:59:07 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA20660 for ; Thu, 23 Mar 1995 12:58:44 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id WAA24453 for ; Thu, 23 Mar 1995 22:58:21 +0200 Message-Id: <199503232058.WAA24453@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: ports@FreeBSD.org Subject: Update for X11 port Date: Thu, 23 Mar 1995 22:58:21 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk Hello All Here is a patch for XFree86 to allow the proud owner of "The X Companion CD for R6" from O'Reilly and Associates, Inc, to mount and compile X on this CD. I have tried to create this patch in such a way that if any other CD's come along, they can be kluged in too. (This CD comes with a book (~100 pages), and I recommend it highly!) -------------------------8<----------------------------------- diff -cdPr XFree86/Makefile XFMM/Makefile *** XFree86/Makefile Wed Mar 22 22:14:36 1995 --- XFMM/Makefile Thu Mar 23 22:06:53 1995 *************** *** 1,10 **** ! # uncomment one of the 2 lines below! ! #X11_ON_CDROM = yes ! X11_VIA_FTP = yes #if you are compiling from a cdrom, set the directory where the # the patch files are ! #X11FIXES = /home/X11R6 #define this if you are short of space - save ~28 Mbytes #REMOVE_NOT_ESSENTIAL = yes --- 1,12 ---- ! # uncomment one of the 3 lines below! ! #(X-Consortium CDROM, O'Reilly 'X-Companion' CDROM, or X by FTP (_*BIG*_) ! #X11_ON_X_CDROM = yes ! #X11_ON_OR_CDROM = yes ! #X11_VIA_FTP = yes #if you are compiling from a cdrom, set the directory where the # the patch files are ! X11FIXES = /usr/ports/distfiles/xc #define this if you are short of space - save ~28 Mbytes #REMOVE_NOT_ESSENTIAL = yes *************** *** 17,22 **** --- 19,28 ---- EXTRACT_COOKIE?= ${WRKDIR}/.extract_done IS_INTERACTIVE= yes + .if defined(X11_ON_X_CDROM) || defined(X11_ON_OR_CDROM) + X11_ON_CDROM = yes + .endif + .if defined(X11_ON_CDROM) || defined(X11_VIA_FTP) build: configure ${BUILD_COOKIE} *************** *** 51,56 **** --- 57,68 ---- @mkdir -p ${WRKDIR} @echo ${X11FIXES} > ${WRKDIR}/.cdrom @${TOUCH} ${TOUCH_FLAGS} ${EXTRACT_COOKIE} + .if defined(X11_ON_X_CDROM) + ${TOUCH} ${TOUCH_FLAGS} ${WRKDIR}/.cd_X + .endif + .if defined(X11_ON_OR_CDROM) + ${TOUCH} ${TOUCH_FLAGS} ${WRKDIR}/.cd_OR + .endif .elif defined(X11_VIA_FTP) .include "Makefile.ftp" diff -cdPr XFree86/scripts/configure XFMM/scripts/configure *** XFree86/scripts/configure Wed Mar 22 22:14:05 1995 --- XFMM/scripts/configure Thu Mar 23 21:51:02 1995 *************** *** 27,41 **** yesno "Is your cdrom distibution already patched? [y] "; if [ $answ = YES ]; then ! echo -n "What is the patchlevel of the distribution? [3] "; ! read pl; if [ X$pl = X ]; then pl=3; fi pl=`expr $pl + 1` if [ $pl -lt 10 ]; then pl=0$pl; fi else pl=01 fi echo "==> building the tree (please wait)" ! (cd $WRKDIR; sh $FILESDIR/maketree $X11R6) else X11FIXES=`cat $WRKDIR/.ftp` pl=01 --- 27,46 ---- yesno "Is your cdrom distibution already patched? [y] "; if [ $answ = YES ]; then ! echo -n "What is the patchlevel of the distribution? [5] "; ! read pl; if [ X$pl = X ]; then pl=5; fi pl=`expr $pl + 1` if [ $pl -lt 10 ]; then pl=0$pl; fi else pl=01 fi echo "==> building the tree (please wait)" ! if [ -f ${WRKDIR}/.cd_OR ] ; then ! (cd $WRKDIR; cp $X11R6/xc/config/util/lndir.c .; cc -o lndir lndir.c; mkdir ./xc; ./lndir $X11R6/xc ./xc) ! fi ! if [ -f ${WRKDIR}/.cd_X ] ; then ! (cd $WRKDIR; sh $FILESDIR/maketree $X11R6) ! fi else X11FIXES=`cat $WRKDIR/.ftp` pl=01 Only in XFree86: work -------------------------8<----------------------------------- M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Thu Mar 23 13:34:32 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA21570 for ports-outgoing; Thu, 23 Mar 1995 13:34:32 -0800 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA21563 for ; Thu, 23 Mar 1995 13:34:27 -0800 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA04986; Thu, 23 Mar 95 22:33:08 +0100 Date: Thu, 23 Mar 95 22:33:08 +0100 From: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Message-Id: <9503232133.AA04986@cabri.obs-besancon.fr> To: mark@grondar.za Cc: ports@FreeBSD.org In-Reply-To: <199503232058.WAA24453@grunt.grondar.za> (message from Mark Murray on Thu, 23 Mar 1995 22:58:21 +0200) Subject: Re: Update for X11 port X-Mailer: Emacs Sender: ports-owner@FreeBSD.org Precedence: bulk >>>>> "Mark" == Mark Murray writes: > Hello All > Here is a patch for XFree86 to allow the proud owner of "The X Companion > CD for R6" from O'Reilly and Associates, Inc, to mount and compile X on > this CD. I have tried to create this patch in such a way that if any other > CD's come along, they can be kluged in too. > (This CD comes with a book (~100 pages), and I recommend it highly!) Thanks for the patch. However I didn't keep your change of the default patchlevel (3->5) since this correspond to the pl. of my cdrom :-) (I have ``The official X Consortium Release'' from Walnut Creek) Jean-Marc. ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Jean-Marc Zucconi | jmz@cabri.obs-besancon.fr Observatoire de Besancon | F 25010 Besancon cedex | PGP Key: finger jmz@cabri.obs-besancon.fr ========================================================================= From owner-freebsd-ports Thu Mar 23 14:01:02 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA22571 for ports-outgoing; Thu, 23 Mar 1995 14:01:02 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA22565 for ; Thu, 23 Mar 1995 14:01:00 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id OAA11008 for ports@freebsd.org; Thu, 23 Mar 1995 14:00:46 -0800 From: Poul-Henning Kamp Message-Id: <199503232200.OAA11008@ref.tfs.com> Subject: expect & majordomo requests To: ports@FreeBSD.org Date: Thu, 23 Mar 1995 14:00:46 -0800 (PST) Content-Type: text Content-Length: 341 Sender: ports-owner@FreeBSD.org Precedence: bulk 1) I don't think I have seen any commits to "expect", it has been updated and the md5 fails. 2) Why havn't we got a port of majordomo ? (I know it's simple!) -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-ports Thu Mar 23 14:17:49 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23385 for ports-outgoing; Thu, 23 Mar 1995 14:17:49 -0800 Received: from rivers.oscs.montana.edu (rivers.oscs.montana.edu [192.31.215.70]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA23379 for ; Thu, 23 Mar 1995 14:17:44 -0800 Received: by rivers.oscs.montana.edu (5.65/DEC-Ultrix/4.3) id AA16782; Thu, 23 Mar 1995 15:17:27 -0700 Date: Thu, 23 Mar 1995 15:17:27 -0700 (MST) From: Jason Boerner To: Howard Lew Cc: Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?= , Ports@FreeBSD.org Subject: Re: Xpaint port... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk This is probably due to the fact that your num-lock is on. I had the same problem with X-Man. Does anyone know the reason for this togle? It just strikes me as odd to have Mouse actions toggled by the num-lock. On Thu, 23 Mar 1995, Howard Lew wrote: > > Well... all xpaint talk has led me to try out the package... > > Has anyone tried the xpaint package in the packages directory? Xpaint > seems to run, but when I click a button and hold down the button to > choose a menu option, I don't see a menu bar (although the pull down > menu shows up). > > Or is my setup wrong...? I'm using XF86_S3 (version 3.1.1) under 16 bit > color mode. > > I recompiled xpaint from the ports directory with the patches aa-ae > sucessfully, but the problem is still there. > > Hmmm... Any ideas? > > Xfig works great though. Thanks guys! > > > > Howard > From owner-freebsd-ports Thu Mar 23 14:46:10 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA24396 for ports-outgoing; Thu, 23 Mar 1995 14:46:10 -0800 Received: from postoffice3.mail.cornell.edu (POSTOFFICE3.MAIL.CORNELL.EDU [132.236.56.11]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA24360; Thu, 23 Mar 1995 14:45:20 -0800 Received: from [128.84.254.37] (CS-ANNEX-1-07.CS.CORNELL.EDU [128.84.254.37]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id RAA08715; Thu, 23 Mar 1995 17:44:54 -0500 Message-Id: <199503232244.RAA08715@postoffice3.mail.cornell.edu> Date: Thu, 23 Mar 1995 17:51:53 +2327 To: freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org, freebsd-platforms@FreeBSD.org, freebsd-hardware@FreeBSD.org From: ds41@cornell.edu (Daisuke Sasaki) X-Sender: ds41@postoffice3.mail.cornell.edu Subject: FreeBSD on Houdini ? MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.5-J10) Sender: ports-owner@FreeBSD.org Precedence: bulk Dear Sirs, I'm wondering if somebody out there have ever tried to run {Free | Net}BSD or other PC-UNIX on the latest DOS Compatible Power Mac 6100/66 called "Houdini" released around early this year ???? And how did it go ? Or is it possible to run *BSD on "Huudini" machine ? Thanks for any help in advance. -- daisuke From owner-freebsd-ports Thu Mar 23 15:22:21 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA25484 for ports-outgoing; Thu, 23 Mar 1995 15:22:21 -0800 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA25477 for ; Thu, 23 Mar 1995 15:22:20 -0800 Received: (from bugs@localhost) by ns1.win.net (8.6.9/8.6.9) id SAA07571 for ports@FreeBSD.ORG; Thu, 23 Mar 1995 18:24:03 -0500 From: Mark Hittinger Message-Id: <199503232324.SAA07571@ns1.win.net> Subject: expect & majordomo requests (fwd) To: ports@FreeBSD.org Date: Thu, 23 Mar 1995 18:24:03 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 354 Sender: ports-owner@FreeBSD.org Precedence: bulk > From: Poul-Henning Kamp > 2) > Why havn't we got a port of majordomo ? (I know it's simple!) > I recently installed majordomo-1.92 with some success. Afterwards I noticed that there is now a majordomo-1.93 on greatcircle. This version has a non-commercial use license attached to it. FYI. Regards, Mark Hittinger bugs@win.net From owner-freebsd-ports Thu Mar 23 22:08:56 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA16659 for ports-outgoing; Thu, 23 Mar 1995 22:08:56 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA16635 for ; Thu, 23 Mar 1995 22:08:40 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id IAA22195; Fri, 24 Mar 1995 08:07:51 +0200 Message-Id: <199503240607.IAA22195@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) cc: mark@grondar.za, ports@FreeBSD.org Subject: Re: Update for X11 port Date: Fri, 24 Mar 1995 08:07:50 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > Thanks for the patch. However I didn't keep your change of the default > patchlevel (3->5) since this correspond to the pl. of my cdrom :-) (I have > ``The official X Consortium Release'' from Walnut Creek) No problem. Pity about the patchlevel ;-) Do you reckon you could swing it so that the bits not on the CDROMs like the XFree86 bits and the extra patches get put onto the FreeBSD 2.1 CDROM too? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Fri Mar 24 06:07:12 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA15325 for ports-outgoing; Fri, 24 Mar 1995 06:07:12 -0800 Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id GAA15316 for ; Fri, 24 Mar 1995 06:07:09 -0800 Received: from dude.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA27074; Fri, 24 Mar 95 06:00:13 -0800 Received: by dude.pcs.dec.com (/\=-/\ Smail3.1.16.1 #16.37) id ; Fri, 24 Mar 95 14:57 MEZ Message-Id: From: me@dude.pcs.dec.com ( Michael Elbel ) Subject: Would someone please commit this? To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Fri, 24 Mar 1995 14:57:40 +0100 (MEZ) Cc: ports@FreeBSD.org Reply-To: me@FreeBSD.org (Michael Elbel) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1626 Sender: ports-owner@FreeBSD.org Precedence: bulk to ports/utils mmv, the featurefull multiple mv/cp/ln/append tool with sophisticated patternmatching. Wanna move all your *.blah.*.cc files to cc/blah/*/*.C ? No problem, mmv will do it for you and even tell you about stuff it's going to overwrite. it's in ~me/src/mmv. I'm a bit unsure about whether the distribution files can go on the CD though. It *only* found it in the comp.sources archives, thus must have been posted on usenet. Nevertheless, the Author gives two different copyrights in two places: --- in announce Mmv is freeware. That means that the entire package of software and documentation is copyrighted, and may not be distributed with any modifications or for any charge (without the author's explicit written permission). Other than that, it may be used and distributed freely. --- >From this I'd say WC can't redistriute it. But then so my internet provider wouldn't be allowed to let me download it via ftp if I got charged volume rates. Theoretically I wouldn't even be allowed to apply the distributed patch and put it up as a tarball. Here's the second: --- in mmv.c This program may be freely used and copied on a non-commercial basis. -- That sounds better. Nevertheless still no CD I think. I've tried to contact the Author and get permission but got no answer :-( So I've implemented it in a way that the port fetches the shar archive and patch, munches it together and compiles. What do people think, will it have to go into LEGAL or am I overly paranoid? Michael -- Michael Elbel, Digital-PCS GmbH, Muenchen, Germany - me@FreeBSD.org Fermentation fault (coors dumped) From owner-freebsd-ports Fri Mar 24 08:59:35 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA09425 for ports-outgoing; Fri, 24 Mar 1995 08:59:35 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA09416; Fri, 24 Mar 1995 08:59:34 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: me@FreeBSD.org (Michael Elbel) cc: ports@FreeBSD.org Subject: Re: Would someone please commit this? In-reply-to: Your message of "Fri, 24 Mar 95 14:57:40 +0100." Date: Fri, 24 Mar 1995 08:59:33 -0800 Message-ID: <9415.796064373@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > What do people think, will it have to go into LEGAL or am I overly > paranoid? Until you get a clearer statement from the author, it should go into LEGAL. Jordan From owner-freebsd-ports Fri Mar 24 10:11:39 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA14811 for ports-outgoing; Fri, 24 Mar 1995 10:11:39 -0800 Received: from kryten.atinc.com (kryten.atinc.com [198.138.38.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA14804 for ; Fri, 24 Mar 1995 10:11:36 -0800 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id NAA05848; Fri, 24 Mar 1995 13:06:37 -0500 Date: Fri, 24 Mar 1995 13:06:36 -0500 (EST) From: "Jonathan M. Bresler" Subject: Re: expect & majordomo requests (fwd) To: Mark Hittinger cc: ports@FreeBSD.org In-Reply-To: <199503232324.SAA07571@ns1.win.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk On Thu, 23 Mar 1995, Mark Hittinger wrote: > > From: Poul-Henning Kamp > > 2) > > Why havn't we got a port of majordomo ? (I know it's simple!) > > > > I recently installed majordomo-1.92 with some success. Afterwards I > noticed that there is now a majordomo-1.93 on greatcircle. This version > has a non-commercial use license attached to it. FYI. majordomo-1.92 works great under 1.1.5.1 majordomo-1.93 has some problems that are being addressed at this time, but it would be premature to switch to 1.93 when do ports close for 2.1? i'll sign up to do the majordomo-1.92 port we are retaining perl-4.036, right. right? jmb Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-ports Fri Mar 24 10:55:46 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA15818 for ports-outgoing; Fri, 24 Mar 1995 10:55:46 -0800 Received: from vegemite.Stanford.EDU (2842@vegemite.Stanford.EDU [36.159.0.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA15812 for ; Fri, 24 Mar 1995 10:55:45 -0800 Received: (hlew@localhost) by vegemite.Stanford.EDU (8.6.10/8.6.4) id KAA14225; Fri, 24 Mar 1995 10:55:41 -0800 Date: Fri, 24 Mar 1995 10:55:41 -0800 (PST) From: Howard Lew To: Jason Boerner cc: Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?= , Ports@FreeBSD.org Subject: Re: Xpaint port... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk On Thu, 23 Mar 1995, Jason Boerner wrote: > This is probably due to the fact that your num-lock is on. I had the > same problem with X-Man. Yep, you're right. I got xpaint working now. This fix also solves the problem of why xv will not let me mouse-click to grab an image off of the screen (the num-lock key was on). > > Does anyone know the reason for this togle? It just strikes me as odd to > have Mouse actions toggled by the num-lock. > > Yep. I agree. Thanks for your help. > On Thu, 23 Mar 1995, Howard Lew wrote: > > > > > Well... all xpaint talk has led me to try out the package... > > > > Has anyone tried the xpaint package in the packages directory? Xpaint > > seems to run, but when I click a button and hold down the button to > > choose a menu option, I don't see a menu bar (although the pull down > > menu shows up). > > > > Or is my setup wrong...? I'm using XF86_S3 (version 3.1.1) under 16 bit > > color mode. > > > > I recompiled xpaint from the ports directory with the patches aa-ae > > sucessfully, but the problem is still there. > > > > Hmmm... Any ideas? > > > > Xfig works great though. Thanks guys! > > > > > > > > Howard > > > From owner-freebsd-ports Fri Mar 24 11:24:06 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA17298 for ports-outgoing; Fri, 24 Mar 1995 11:24:06 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA17290 for ; Fri, 24 Mar 1995 11:24:05 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa27401; 24 Mar 95 18:03 GMT Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id RAA02313 for ; Fri, 24 Mar 1995 17:46:59 GMT X-Authentication-Warning: palmer.demon.co.uk: Host localhost didn't use HELO protocol To: FreeBSD Ports Subject: audio/gmod MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2309.796067216.1@palmer.demon.co.uk> Date: Fri, 24 Mar 1995 17:46:57 +0000 Message-ID: <2310.796067217@palmer.demon.co.uk> From: Gary Palmer Sender: ports-owner@FreeBSD.org Precedence: bulk sunsite.unc.edu:/pub/Linux/apps/sound/players ncftp>dir total 8116 [...] -rw-r--r-- 1 67 25 145023 Mar 11 18:17 gmod+x-2.0.tgz -rw-r--r-- 1 67 25 969 Mar 11 18:16 gmod+x.lsm Can someone update the port please? Thanks Gary From owner-freebsd-ports Fri Mar 24 11:33:55 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA17526 for ports-outgoing; Fri, 24 Mar 1995 11:33:55 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA17519; Fri, 24 Mar 1995 11:33:54 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: "Jonathan M. Bresler" cc: Mark Hittinger , ports@FreeBSD.org Subject: Re: expect & majordomo requests (fwd) In-reply-to: Your message of "Fri, 24 Mar 95 13:06:36 EST." Date: Fri, 24 Mar 1995 11:33:53 -0800 Message-ID: <17518.796073633@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > when do ports close for 2.1? Never, they're ongoing development, though we will *snapshot* the ports collection (with some warning, so folks can clean up any bogons) for the 2.1 CD sometime near the end of April. > i'll sign up to do the majordomo-1.92 port Cool! > we are retaining perl-4.036, right. right? Right. Jordan From owner-freebsd-ports Fri Mar 24 11:46:08 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA17859 for ports-outgoing; Fri, 24 Mar 1995 11:46:08 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA17853 for ; Fri, 24 Mar 1995 11:46:03 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa04052; 24 Mar 95 18:29 GMT Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id SAA02462; Fri, 24 Mar 1995 18:27:33 GMT X-Authentication-Warning: palmer.demon.co.uk: Host localhost didn't use HELO protocol To: "Jonathan M. Bresler" cc: FreeBSD Ports Subject: Re: expect & majordomo requests (fwd) In-reply-to: Your message of "Fri, 24 Mar 1995 13:06:36 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2458.796069650.1@palmer.demon.co.uk> Date: Fri, 24 Mar 1995 18:27:31 +0000 Message-ID: <2459.796069651@palmer.demon.co.uk> From: Gary Palmer Sender: ports-owner@FreeBSD.org Precedence: bulk In message , "Jonathan M. B resler" writes: > when do ports close for 2.1? Interesting question. I'd like to see some sort of port/package testing done this time to avoid the mess we got on the 2.0 CDROM. Should we go through an ALPHA/BETA/RELEASE schedule also? Or is that stupid? Gary From owner-freebsd-ports Fri Mar 24 12:01:18 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA18256 for ports-outgoing; Fri, 24 Mar 1995 12:01:18 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA18249; Fri, 24 Mar 1995 12:01:17 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Gary Palmer cc: "Jonathan M. Bresler" , FreeBSD Ports Subject: Re: expect & majordomo requests (fwd) In-reply-to: Your message of "Fri, 24 Mar 95 18:27:31 GMT." <2459.796069651@palmer.demon.co.uk> Date: Fri, 24 Mar 1995 12:01:16 -0800 Message-ID: <18247.796075276@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > In message , "Jonathan M. B > resler" writes: > > when do ports close for 2.1? > > Interesting question. > > I'd like to see some sort of port/package testing done this time to avoid > the mess we got on the 2.0 CDROM. > > Should we go through an ALPHA/BETA/RELEASE schedule also? Or is that stupid? > > Gary I have no objections if you want to be that detailed about it. Sure! Jordan From owner-freebsd-ports Fri Mar 24 18:10:31 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA27920 for ports-outgoing; Fri, 24 Mar 1995 18:10:31 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA27914 for ; Fri, 24 Mar 1995 18:10:30 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id SAA16130 for ports@freebsd.org; Fri, 24 Mar 1995 18:10:27 -0800 From: Poul-Henning Kamp Message-Id: <199503250210.SAA16130@ref.tfs.com> Subject: kermit port doesn't build To: ports@FreeBSD.org Date: Fri, 24 Mar 1995 18:10:27 -0800 (PST) Content-Type: text Content-Length: 605 Sender: ports-owner@FreeBSD.org Precedence: bulk flagmose# cd /usr/ports/*/kermit flagmose# make >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch it from a master site. Receiving file: cku190.tar.gz 100% 0 911861 bytes. ETA: 0:00 cku190.tar.gz: 911861 bytes received in 359.15 seconds, 2.48 K/s. >> Checksum mismatch for cku190.tar.gz *** Error code 1 Stop. *** Error code 1 Stop. flagmose# -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant' From owner-freebsd-ports Sat Mar 25 00:07:07 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA11873 for ports-outgoing; Sat, 25 Mar 1995 00:07:07 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA11867 for ; Sat, 25 Mar 1995 00:07:02 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id AAA29426; Sat, 25 Mar 1995 00:06:42 -0800 Date: Sat, 25 Mar 1995 00:06:42 -0800 Message-Id: <199503250806.AAA29426@silvia.HIP.Berkeley.EDU> To: chaos@rivers.oscs.montana.edu CC: ports@FreeBSD.org In-reply-to: (message from Jason Boerner on Wed, 22 Mar 1995 19:47:46 -0700 (MST)) Subject: Re: non-initial installation From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * ***NOTE TO SOMEONE WHO KNOWS A LOT ABOUT THESE PORT INSTALL METHODES: * I believe that this not only build the files but installs (make * install) them. However they do not show up with pkg_info -a. * * Does anyone know how to/where to fix this at? This and fixing the uemacs * port are my next too little assignments. I've thinking about this for a while. I think it would be very useful if we can make it possible to "deinstall" ports from the ports dir by using the Makefile and pkg/PLIST, as there should be enough information in there to determine which files should be deleted. Currently I do a "make package" and "pkg_add" following a "make install" to ensure the package is registered (so that I can deinstall it). But this is kinda redundant. Another idea is to automatically "register" the port into /var/db/ports when we do "make install" by copying the PLIST file with appropriate modifications. Then we don't have to touch pkg_delete. Also, this way we can ensure we have the right version of the packing list when we do a deinstall. What do people think? Satoshi From owner-freebsd-ports Sat Mar 25 03:29:06 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA17586 for ports-outgoing; Sat, 25 Mar 1995 03:29:06 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA17580 for ; Sat, 25 Mar 1995 03:28:54 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id NAA10783; Sat, 25 Mar 1995 13:28:18 +0200 Message-Id: <199503251128.NAA10783@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: chaos@rivers.oscs.montana.edu, ports@FreeBSD.org Subject: Re: non-initial installation Date: Sat, 25 Mar 1995 13:28:18 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > I've thinking about this for a while. I think it would be very useful > if we can make it possible to "deinstall" ports from the ports dir by > using the Makefile and pkg/PLIST, as there should be enough > information in there to determine which files should be deleted. > > Currently I do a "make package" and "pkg_add" following a "make > install" to ensure the package is registered (so that I can deinstall > it). But this is kinda redundant. > > Another idea is to automatically "register" the port into > /var/db/ports when we do "make install" by copying the PLIST file with > appropriate modifications. Then we don't have to touch pkg_delete. > Also, this way we can ensure we have the right version of the packing > list when we do a deinstall. > > What do people think? I don't really mind which one you use, but whichever it is, YES PLEASE! Another idea: whenever a big system change comes along, I want to be able to recompile all the ports _I_ use. How about some kind of _really_ simple file that is included into the ports/Makefile _if_it_exists_, that forces a make to make only a selected subset of ports? This file should obviously never be messed with by sup/ctm. (Or am i being a real twit and not noticing that such a mechanism already exists?) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sat Mar 25 07:29:41 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA24593 for ports-outgoing; Sat, 25 Mar 1995 07:29:41 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA24582; Sat, 25 Mar 1995 07:29:39 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) cc: chaos@rivers.oscs.montana.edu, ports@FreeBSD.org Subject: Re: non-initial installation In-reply-to: Your message of "Sat, 25 Mar 95 00:06:42 PST." <199503250806.AAA29426@silvia.HIP.Berkeley.EDU> Date: Sat, 25 Mar 1995 07:29:38 -0800 Message-ID: <24581.796145378@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: ports-owner@FreeBSD.org Precedence: bulk > I've thinking about this for a while. I think it would be very useful > if we can make it possible to "deinstall" ports from the ports dir by > using the Makefile and pkg/PLIST, as there should be enough > information in there to determine which files should be deleted. Hmmmmmmm. Well, I can say one thing: It would make the PLIST writers a lot more honest! :-) (e.g. we wouldn't have the traditional disjoint between what you get with a make install or a pkg_add for some of the ports). I like the idea. "Make it so", Satoshi! :-) Jordan From owner-freebsd-ports Sat Mar 25 10:42:45 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA29793 for ports-outgoing; Sat, 25 Mar 1995 10:42:45 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA29782 for ; Sat, 25 Mar 1995 10:42:42 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id KAA07789; Sat, 25 Mar 1995 10:41:58 -0800 From: "Rodney W. Grimes" Message-Id: <199503251841.KAA07789@gndrsh.aac.dev.com> Subject: Re: non-initial installation To: mark@grondar.za (Mark Murray) Date: Sat, 25 Mar 1995 10:41:57 -0800 (PST) Cc: asami@cs.berkeley.edu, chaos@rivers.oscs.montana.edu, ports@FreeBSD.org In-Reply-To: <199503251128.NAA10783@grunt.grondar.za> from "Mark Murray" at Mar 25, 95 01:28:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1709 Sender: ports-owner@FreeBSD.org Precedence: bulk > > > I've thinking about this for a while. I think it would be very useful > > if we can make it possible to "deinstall" ports from the ports dir by > > using the Makefile and pkg/PLIST, as there should be enough > > information in there to determine which files should be deleted. > > > > Currently I do a "make package" and "pkg_add" following a "make > > install" to ensure the package is registered (so that I can deinstall > > it). But this is kinda redundant. > > > > Another idea is to automatically "register" the port into > > /var/db/ports when we do "make install" by copying the PLIST file with > > appropriate modifications. Then we don't have to touch pkg_delete. > > Also, this way we can ensure we have the right version of the packing > > list when we do a deinstall. > > > > What do people think? > > I don't really mind which one you use, but whichever it is, YES PLEASE! > > Another idea: whenever a big system change comes along, I want to be able > to recompile all the ports _I_ use. How about some kind of _really_ simple > file that is included into the ports/Makefile _if_it_exists_, that forces > a make to make only a selected subset of ports? This file should obviously > never be messed with by sup/ctm. (Or am i being a real twit and not noticing > that such a mechanism already exists?) Pretty simple, /usr/ports/makefile ^ make will read makefile before Makefile. In makefile you would do something like this: SUBDIR= comms/kermit comms/rzsz devel/gmake net/sup Works for me.... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-ports Sat Mar 25 13:43:44 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA13333 for ports-outgoing; Sat, 25 Mar 1995 13:43:44 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA13314 for ; Sat, 25 Mar 1995 13:43:25 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.11/8.6.9) with SMTP id XAA00899; Sat, 25 Mar 1995 23:41:53 +0200 Message-Id: <199503252141.XAA00899@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: mark@grondar.za (Mark Murray), asami@cs.berkeley.edu, chaos@rivers.oscs.montana.edu, ports@FreeBSD.org Subject: Re: non-initial installation Date: Sat, 25 Mar 1995 23:41:52 +0200 From: Mark Murray Sender: ports-owner@FreeBSD.org Precedence: bulk > Pretty simple, /usr/ports/makefile > ^ > > make will read makefile before Makefile. In makefile you would do > something like this: > > SUBDIR= comms/kermit comms/rzsz devel/gmake net/sup > > Works for me.... I thought it might be something simple (and not immediately obvious). In general terms, this is good to know. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-ports Sat Mar 25 15:31:20 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA18111 for ports-outgoing; Sat, 25 Mar 1995 15:31:20 -0800 Received: from uclink.berkeley.edu (uclink.Berkeley.EDU [128.32.155.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA18094; Sat, 25 Mar 1995 15:31:13 -0800 Received: by uclink.berkeley.edu (8.6.10/1.33(web)-OV4) id PAA15136; Sat, 25 Mar 1995 15:31:09 -0800 Date: Sat, 25 Mar 1995 15:31:09 -0800 (PST) From: Yu Sylvia Fong Subject: FreeBSD Connected to Wyse Terminals? To: jkh@FreeBSD.org, hackers@FreeBSD.org, ports@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk Anyone have information on connecting Wyse 30 terminals to a machine running FreeBSD 2.0? What kind of cables and adjustments would be required? The terminals would be used for users to log in and do basic stuff such as checking mail and such. From owner-freebsd-ports Sat Mar 25 16:32:45 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA20152 for ports-outgoing; Sat, 25 Mar 1995 16:32:45 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA20146 for ; Sat, 25 Mar 1995 16:32:43 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa17638; 26 Mar 95 0:31 GMT Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id AAA00615 for ; Sun, 26 Mar 1995 00:30:11 GMT X-Authentication-Warning: palmer.demon.co.uk: Host localhost didn't use HELO protocol To: FreeBSD Ports Subject: duds MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <610.796177807.1@palmer.demon.co.uk> Date: Sun, 26 Mar 1995 00:30:08 +0000 Message-ID: <611.796177808@palmer.demon.co.uk> From: Gary Palmer Sender: ports-owner@FreeBSD.org Precedence: bulk Well, with 2.1 leering at us from round the corner, I feel it's time to really tighten things up. Here's the first round of real duds : ===> archivers/gshar+gunshar >> sharutils-4.1.3.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.iro.umontreal.ca/pub/contrib/pinard/ /pub/contrib/pinard/sharutils-4.1.3.tar.gz: No such file. ===> audio/gmod >> gmod1.4.tgz doesn't seem to exist on this system. >> Attempting to fetch from ftp://sunsite.unc.edu/pub/Linux/apps/sound/players/ /pub/Linux/apps/sound/players/gmod1.4.tgz: No such file. ===> cad/pcb >> pcb-1.2.patch_02.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://pluto.medizin.uni-ulm.de/pub/pcb-1.2/ /pub/pcb-1.2/pcb-1.2.patch_02.tar.gz: No such file. ===> comms/flexfax >> flexfax-v2.3beta036special-tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://sgi.com/sgi/fax/source/. /sgi/fax/source/flexfax-v2.3beta036special-tar.gz: No such file. ===> games/acm >> acm.tar.Z doesn't seem to exist on this system. >> Attempting to fetch from ftp://hpsystem2.informatik.tu-muenchen.de/pub/comp/usenet/comp.sources.x/acm/. /pub/comp/usenet/comp.sources.x/acm/acm.tar.Z: No such file. ===> games/golddig >> golddig2.tar.z doesn't seem to exist on this system. >> Attempting to fetch from ftp://ss7.vlsi.ee.nus.sg/pub/games/X/. /pub/games/X/golddig2.tar.z: No such file. ===> games/jetpack >> jetpack.tar.Z doesn't seem to exist on this system. >> Attempting to fetch from ftp://iraun1.ira.uka.de/pub/x11/. /pub/x11/jetpack.tar.Z: No such file. ===> games/xboing >> xboing2.2.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.icm.edu.pl/pub/X11/contrib/games/. /pub/X11/contrib/games/xboing2.2.tar.gz: No such file. ===> games/xchomp >> xchomp.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://freebsd.cdrom.com/pub/FreeBSD/FreeBSD-current/ports/distfiles/. /pub/FreeBSD/FreeBSD-current/ports/distfiles/xchomp.tar.gz: No such file. ===> games/xinvaders >> xinvaders.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://romulus.ucs.uoknor.edu/Linux/games/x11/action/. /Linux/games/x11/action/xinvaders.tar.gz: No such file. ===> games/xmine >> xmine-1.0.3-Xaw.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://freebsd.cdrom.com/pub/FreeBSD/FreeBSD-current/ports/distfiles/. /pub/FreeBSD/FreeBSD-current/ports/distfiles/xmine-1.0.3-Xaw.tar.gz: No such file. ===> games/xpipeman >> xpipeman.tar.Z doesn't seem to exist on this system. >> Attempting to fetch from ftp://iraun1.ira.uka.de/pub/x11/. /pub/x11/xpipeman.tar.Z: No such file. ===> games/xsol >> xsol-new.tar.Z doesn't seem to exist on this system. >> Attempting to fetch from ftp://iraun1.ira.uka.de/pub/x11/games/. /pub/x11/games/xsol-new.tar.Z: No such file. ===> graphics/ImageMagick >> ImageMagick-3.5.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.x.org/contrib/applications/ImageMagick/. /contrib/applications/ImageMagick/ImageMagick-3.5.tar.gz: No such file. ===> lang/scm >> scm4e1.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://swiss-ftp.ai.mit.edu/pub/scm/. >> slib.info.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://swiss-ftp.ai.mit.edu/pub/scm/. >> slib2a1.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://swiss-ftp.ai.mit.edu/pub/scm/. /pub/scm/slib2a1.tar.gz: No such file. Gary From owner-freebsd-ports Sat Mar 25 17:33:50 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA21813 for ports-outgoing; Sat, 25 Mar 1995 17:33:50 -0800 Received: from seldon.apanix.apana.org.au (seldon.apanix.apana.org.au [192.203.213.8]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA21799 for ; Sat, 25 Mar 1995 17:33:37 -0800 Received: from ldjpc.apana.org.au (ldjpc.apana.org.au [192.203.213.254]) by seldon.apanix.apana.org.au (8.6.10/8.6.9) with ESMTP id MAA12236; Sun, 26 Mar 1995 12:03:28 +0930 Received: (from jj@localhost) by ldjpc.apana.org.au (8.6.9/8.6.9) id QAA00439; Sat, 25 Mar 1995 16:58:59 +0930 Date: Sat, 25 Mar 1995 16:58:58 +0930 (CST) From: Lucas James To: bmk@dtr.com cc: ports@FreeBSD.org Subject: Re: problems with inn port In-Reply-To: <199503230639.WAA28535@dtr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk On Wed, 22 Mar 1995 bmk@dtr.com wrote: > I've compiled and configured the news/inn port... When I fire up > /etc/rc.news, I get the following on my syslog: > > Mar 22 22:29:50 everest innd: ME descriptors 128 > Mar 22 22:29:50 everest innd: ME outgoing 115 > Mar 22 22:29:50 everest innd: /usr/local/news/lib/history cant dbminit ME No > such file or directory > > innd then dies without further comment. > > innd -s does not report any errors with my newsgroups file, and I have > run makehistory. This is on a fresh news install. > > Anyone want to clue me in as to what I've missed? After you run makehistory, it makes the files history, history.n.pag and history.n.dir You must rename the history.n.* to history.* ie: mv history.n.pag history.pag mv history.n.dir history.dir Fire up the server, and duck for cover ! YMMV of course. -- Lucas James jj@ldjpc.apana.org.au From owner-freebsd-ports Sat Mar 25 22:04:22 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA01638 for ports-outgoing; Sat, 25 Mar 1995 22:04:22 -0800 Received: from dream.demos.su (dream.demos.su [192.91.186.135]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA01632 for ; Sat, 25 Mar 1995 22:04:10 -0800 Received: by dream.demos.su id KAA21682; (8.6.8/D) Sun, 26 Mar 1995 10:03:47 +0400 To: ports@FreeBSD.org Message-ID: Organization: Demos, Moscow, Russia Date: Sun, 26 Mar 1995 10:03:46 +0400 X-Mailer: Mail/@ [v2.22 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: ports/XFree86 configure pass problems... Lines: 460 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 28475 Sender: ports-owner@FreeBSD.org Precedence: bulk I have FTPed xc files. Log follows. Any ideas? ===> Extracting for xc ===> Configuring for xc ==> applying XC patches (please wait).This file doesn't appear to be the initial-release version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-1 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-2 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-3 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-4 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-5 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-6 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-7 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-8 version--patch anyway? [n] patch: **** aborted .This file doesn't appear to be the public-patch-9 version--patch anyway? [n] patch: **** aborted Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/courR18.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/75dpi/courR24.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/helvB08.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/75dpi/helvR10.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/75dpi/helvB12.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/75dpi/courB14.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/75dpi/courB18.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/75dpi/courB24.bdf.rej Ignoring previously applied (or reversed) patch. 210 out of 210 hunks ignored--saving rejects to fonts/bdf/75dpi/courBO08.bdf.rej Ignoring previously applied (or reversed) patch. 10 out of 10 hunks ignored--saving rejects to fonts/bdf/75dpi/courBO10.bdf.rej Ignoring previously applied (or reversed) patch. 10 out of 10 hunks ignored--saving rejects to fonts/bdf/75dpi/courBO12.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/75dpi/courBO14.bdf.rej Ignoring previously applied (or reversed) patch. 20 out of 20 hunks ignored--saving rejects to fonts/bdf/75dpi/courBO18.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/75dpi/courBO24.bdf.rej Ignoring previously applied (or reversed) patch. 194 out of 194 hunks ignored--saving rejects to fonts/bdf/75dpi/courO08.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/75dpi/symb08.bdf.rej Ignoring previously applied (or reversed) patch. 9 out of 9 hunks ignored--saving rejects to fonts/bdf/75dpi/courO12.bdf.rej Ignoring previously applied (or reversed) patch. 50 out of 50 hunks ignored--saving rejects to fonts/bdf/75dpi/helvBO18.bdf.rej Ignoring previously applied (or reversed) patch. 10 out of 10 hunks ignored--saving rejects to fonts/bdf/75dpi/courO14.bdf.rej Ignoring previously applied (or reversed) patch. 19 out of 19 hunks ignored--saving rejects to fonts/bdf/75dpi/courO18.bdf.rej Ignoring previously applied (or reversed) patch. 12 out of 12 hunks ignored--saving rejects to fonts/bdf/75dpi/courO24.bdf.rej Ignoring previously applied (or reversed) patch. 11 out of 11 hunks ignored--saving rejects to fonts/bdf/75dpi/courR08.bdf.rej Ignoring previously applied (or reversed) patch. 20 out of 20 hunks ignored--saving rejects to fonts/bdf/75dpi/helvR12.bdf.rej Ignoring previously applied (or reversed) patch. 10 out of 10 hunks ignored--saving rejects to fonts/bdf/75dpi/courR12.bdf.rej Ignoring previously applied (or reversed) patch. 21 out of 21 hunks ignored--saving rejects to fonts/bdf/75dpi/helvR18.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/75dpi/helvR24.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenB08.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/helvB10.bdf.rej Ignoring previously applied (or reversed) patch. 22 out of 22 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenB12.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/helvB14.bdf.rej Ignoring previously applied (or reversed) patch. 44 out of 44 hunks ignored--saving rejects to fonts/bdf/75dpi/helvB18.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/75dpi/helvB24.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/75dpi/helvBO08.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/75dpi/helvBO10.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/75dpi/helvBO12.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/helvBO14.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/75dpi/symb10.bdf.rej Ignoring previously applied (or reversed) patch. 23 out of 23 hunks ignored--saving rejects to fonts/bdf/75dpi/helvBO24.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/timBI18.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/75dpi/helvO08.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/75dpi/helvO10.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/helvO12.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/helvO14.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/helvO18.bdf.rej Ignoring previously applied (or reversed) patch. 9 out of 9 hunks ignored--saving rejects to fonts/bdf/75dpi/helvO24.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/helvR08.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenB10.bdf.rej Ignoring previously applied (or reversed) patch. 9 out of 9 hunks ignored--saving rejects to fonts/bdf/75dpi/courB10.bdf.rej Ignoring previously applied (or reversed) patch. 38 out of 38 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenB14.bdf.rej Ignoring previously applied (or reversed) patch. 37 out of 37 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenB18.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenB24.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenBI08.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenBI10.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenBI12.bdf.rej Ignoring previously applied (or reversed) patch. 44 out of 44 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenBI14.bdf.rej Ignoring previously applied (or reversed) patch. 27 out of 27 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenBI18.bdf.rej Ignoring previously applied (or reversed) patch. 6 out of 6 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenBI24.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenI08.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenI10.bdf.rej Ignoring previously applied (or reversed) patch. 22 out of 22 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenI12.bdf.rej Ignoring previously applied (or reversed) patch. 52 out of 52 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenI14.bdf.rej Ignoring previously applied (or reversed) patch. 33 out of 33 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenI18.bdf.rej Ignoring previously applied (or reversed) patch. 22 out of 22 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenI24.bdf.rej Ignoring previously applied (or reversed) patch. 2 out of 2 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenR08.bdf.rej Ignoring previously applied (or reversed) patch. 6 out of 6 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenR10.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenR12.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenR14.bdf.rej Ignoring previously applied (or reversed) patch. 2 out of 2 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenR18.bdf.rej Ignoring previously applied (or reversed) patch. 2 out of 2 hunks ignored--saving rejects to fonts/bdf/75dpi/ncenR24.bdf.rej Ignoring previously applied (or reversed) patch. 20 out of 20 hunks ignored--saving rejects to fonts/bdf/75dpi/timB08.bdf.rej Ignoring previously applied (or reversed) patch. 9 out of 9 hunks ignored--saving rejects to fonts/bdf/75dpi/courO10.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/timB12.bdf.rej Ignoring previously applied (or reversed) patch. 19 out of 19 hunks ignored--saving rejects to fonts/bdf/75dpi/timB14.bdf.rej Ignoring previously applied (or reversed) patch. 39 out of 39 hunks ignored--saving rejects to fonts/bdf/75dpi/timB18.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/75dpi/timB24.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/timBI10.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/timR08.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/75dpi/timBI14.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/75dpi/symb12.bdf.rej Ignoring previously applied (or reversed) patch. 27 out of 27 hunks ignored--saving rejects to fonts/bdf/75dpi/timBI24.bdf.rej Ignoring previously applied (or reversed) patch. 209 out of 209 hunks ignored--saving rejects to fonts/bdf/75dpi/courB08.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/timI08.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/timI10.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/timI12.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/timI14.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/75dpi/timI18.bdf.rej Ignoring previously applied (or reversed) patch. 25 out of 25 hunks ignored--saving rejects to fonts/bdf/75dpi/timI24.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/timR10.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/75dpi/symb18.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/75dpi/timR14.bdf.rej Ignoring previously applied (or reversed) patch. 23 out of 23 hunks ignored--saving rejects to fonts/bdf/75dpi/timR18.bdf.rej Ignoring previously applied (or reversed) patch. 29 out of 29 hunks ignored--saving rejects to fonts/bdf/75dpi/timR24.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/75dpi/symb14.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/75dpi/symb24.bdf.rej Ignoring previously applied (or reversed) patch. 2 out of 2 hunks ignored--saving rejects to fonts/bdf/75dpi/courB12.bdf.rej Ignoring previously applied (or reversed) patch. 19 out of 19 hunks ignored--saving rejects to fonts/bdf/75dpi/timBI12.bdf.rej Ignoring previously applied (or reversed) patch. 34 out of 34 hunks ignored--saving rejects to fonts/bdf/75dpi/timR12.bdf.rej Ignoring previously applied (or reversed) patch. 70 out of 70 hunks ignored--saving rejects to fonts/bdf/75dpi/techB14.bdf.rej Ignoring previously applied (or reversed) patch. 54 out of 54 hunks ignored--saving rejects to fonts/bdf/75dpi/tech14.bdf.rej Ignoring previously applied (or reversed) patch. 25 out of 25 hunks ignored--saving rejects to fonts/bdf/75dpi/term14.bdf.rej Ignoring previously applied (or reversed) patch. 39 out of 39 hunks ignored--saving rejects to fonts/bdf/75dpi/termB14.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/75dpi/timB10.bdf.rej Ignoring previously applied (or reversed) patch. 9 out of 9 hunks ignored--saving rejects to fonts/bdf/75dpi/courR10.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/75dpi/courR14.bdf.rej Ignoring previously applied (or reversed) patch. 20 out of 20 hunks ignored--saving rejects to fonts/bdf/75dpi/helvR14.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/75dpi/timBI08.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/courB08.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/courB10.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/courO14.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/courB18.bdf.rej Ignoring previously applied (or reversed) patch. 6 out of 6 hunks ignored--saving rejects to fonts/bdf/100dpi/courR24.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/courBO08.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/courBO10.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/courR14.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/courBO18.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/courBO14.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/courO08.bdf.rej Ignoring previously applied (or reversed) patch. 10 out of 10 hunks ignored--saving rejects to fonts/bdf/100dpi/courO10.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/100dpi/courO12.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/100dpi/courB12.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/courO18.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/courBO12.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/courR08.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/courR10.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/100dpi/courR12.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/courB14.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/courR18.bdf.rej Ignoring previously applied (or reversed) patch. 6 out of 6 hunks ignored--saving rejects to fonts/bdf/100dpi/courBO24.bdf.rej Ignoring previously applied (or reversed) patch. 6 out of 6 hunks ignored--saving rejects to fonts/bdf/100dpi/helvB08.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/100dpi/helvB10.bdf.rej Ignoring previously applied (or reversed) patch. 8 out of 8 hunks ignored--saving rejects to fonts/bdf/100dpi/courB24.bdf.rej Ignoring previously applied (or reversed) patch. 59 out of 59 hunks ignored--saving rejects to fonts/bdf/100dpi/helvB14.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/helvB18.bdf.rej Ignoring previously applied (or reversed) patch. 19 out of 19 hunks ignored--saving rejects to fonts/bdf/100dpi/helvB24.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/helvBO08.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/100dpi/helvBO10.bdf.rej Ignoring previously applied (or reversed) patch. 20 out of 20 hunks ignored--saving rejects to fonts/bdf/100dpi/helvBO12.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/100dpi/helvBO14.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/100dpi/helvBO18.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/100dpi/helvBO24.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/100dpi/helvO08.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/helvO10.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/100dpi/helvO12.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/100dpi/helvO14.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/helvO18.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/helvO24.bdf.rej Ignoring previously applied (or reversed) patch. 6 out of 6 hunks ignored--saving rejects to fonts/bdf/100dpi/helvR08.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/helvR10.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/helvR12.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/helvR14.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/helvR18.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/helvR24.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenB08.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenB10.bdf.rej Ignoring previously applied (or reversed) patch. 22 out of 22 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenB12.bdf.rej Ignoring previously applied (or reversed) patch. 25 out of 25 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenB14.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenB18.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenB24.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenBI08.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenBI10.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenBI12.bdf.rej Ignoring previously applied (or reversed) patch. 2 out of 2 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenBI14.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenBI18.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenBI24.bdf.rej Ignoring previously applied (or reversed) patch. 9 out of 9 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenI08.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenI10.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenI12.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenI14.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenI18.bdf.rej Ignoring previously applied (or reversed) patch. 12 out of 12 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenI24.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenR08.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenR10.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenR12.bdf.rej Ignoring previously applied (or reversed) patch. 44 out of 44 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenR14.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenR18.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/ncenR24.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/symb08.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/symb10.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/symb12.bdf.rej Ignoring previously applied (or reversed) patch. 5 out of 5 hunks ignored--saving rejects to fonts/bdf/100dpi/symb14.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/100dpi/symb18.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/100dpi/symb24.bdf.rej Ignoring previously applied (or reversed) patch. 32 out of 32 hunks ignored--saving rejects to fonts/bdf/100dpi/tech14.bdf.rej Ignoring previously applied (or reversed) patch. 24 out of 24 hunks ignored--saving rejects to fonts/bdf/100dpi/techB14.bdf.rej Ignoring previously applied (or reversed) patch. 26 out of 26 hunks ignored--saving rejects to fonts/bdf/100dpi/term14.bdf.rej Ignoring previously applied (or reversed) patch. 27 out of 27 hunks ignored--saving rejects to fonts/bdf/100dpi/termB14.bdf.rej Ignoring previously applied (or reversed) patch. 7 out of 7 hunks ignored--saving rejects to fonts/bdf/100dpi/timB08.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/timB10.bdf.rej Ignoring previously applied (or reversed) patch. 33 out of 33 hunks ignored--saving rejects to fonts/bdf/100dpi/timB12.bdf.rej Ignoring previously applied (or reversed) patch. 17 out of 17 hunks ignored--saving rejects to fonts/bdf/100dpi/timB14.bdf.rej Ignoring previously applied (or reversed) patch. 16 out of 16 hunks ignored--saving rejects to fonts/bdf/100dpi/timB18.bdf.rej Ignoring previously applied (or reversed) patch. 45 out of 45 hunks ignored--saving rejects to fonts/bdf/100dpi/timB24.bdf.rej Ignoring previously applied (or reversed) patch. 21 out of 21 hunks ignored--saving rejects to fonts/bdf/100dpi/timBI08.bdf.rej Ignoring previously applied (or reversed) patch. 12 out of 12 hunks ignored--saving rejects to fonts/bdf/100dpi/timBI10.bdf.rej Ignoring previously applied (or reversed) patch. 4 out of 4 hunks ignored--saving rejects to fonts/bdf/100dpi/timBI12.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/timBI14.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/timBI18.bdf.rej Ignoring previously applied (or reversed) patch. 12 out of 12 hunks ignored--saving rejects to fonts/bdf/100dpi/timBI24.bdf.rej Ignoring previously applied (or reversed) patch. 30 out of 30 hunks ignored--saving rejects to fonts/bdf/100dpi/timI08.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/timI10.bdf.rej Ignoring previously applied (or reversed) patch. 12 out of 12 hunks ignored--saving rejects to fonts/bdf/100dpi/timI12.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/timI14.bdf.rej Ignoring previously applied (or reversed) patch. 15 out of 15 hunks ignored--saving rejects to fonts/bdf/100dpi/timI18.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/timI24.bdf.rej Ignoring previously applied (or reversed) patch. 32 out of 32 hunks ignored--saving rejects to fonts/bdf/100dpi/timR08.bdf.rej Ignoring previously applied (or reversed) patch. 18 out of 18 hunks ignored--saving rejects to fonts/bdf/100dpi/timR10.bdf.rej Ignoring previously applied (or reversed) patch. 13 out of 13 hunks ignored--saving rejects to fonts/bdf/100dpi/timR12.bdf.rej Ignoring previously applied (or reversed) patch. 28 out of 28 hunks ignored--saving rejects to fonts/bdf/100dpi/timR14.bdf.rej Ignoring previously applied (or reversed) patch. 26 out of 26 hunks ignored--saving rejects to fonts/bdf/100dpi/timR18.bdf.rej Ignoring previously applied (or reversed) patch. 14 out of 14 hunks ignored--saving rejects to fonts/bdf/100dpi/timR24.bdf.rej Ignoring previously applied (or reversed) patch. 34 out of 34 hunks ignored--saving rejects to fonts/bdf/100dpi/helvB12.bdf.rej Ignoring previously applied (or reversed) patch. 6 out of 6 hunks ignored--saving rejects to fonts/bdf/100dpi/courO24.bdf.rej .This file doesn't appear to be the public-patch-10 version--patch anyway? [n] patch: **** aborted ==> applying XFree86 patches (please wait) -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-ports Sat Mar 25 22:16:38 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02075 for ports-outgoing; Sat, 25 Mar 1995 22:16:38 -0800 Received: (from jmacd@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02068 for ports; Sat, 25 Mar 1995 22:16:38 -0800 Date: Sat, 25 Mar 1995 22:16:38 -0800 From: Joshua Peck Macdonald Message-Id: <199503260616.WAA02068@freefall.cdrom.com> To: ports Subject: bsd.port.mk Sender: ports-owner@FreeBSD.org Precedence: bulk I've been having trouble getting bsd.port.mk to work when supplying an alternate DISTDIR, for example: thud-mit-scheme % make "DISTDIR = ../.." Checksums OK. ===> Extracting for mit-scheme tar: can't open archive ../../scheme-microcode+dist-7.3-freebsd.tgz : No such file or directory tar: child returned status 3 ===> Applying patches for mit-scheme patch: **** can't cd to /home/jmacd/mit-scheme/mit-scheme/work/mit-scheme: No such file or directory *** Error code 1 Stop. As indicated by its passing the md5 test, it does in fact find the file in the DISTDIR, but tar thinks it doesn't work. This happens on thud, freefall, and on a /usr/share/mk tree out of the 950322 snapshot. I thought it was something dumb I was doing(I've been gettings things wrong today) but I'm sure I remember this working before. So... does anyone know what's happening? -josh From owner-freebsd-ports Sat Mar 25 22:21:01 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA02193 for ports-outgoing; Sat, 25 Mar 1995 22:21:01 -0800 Received: from rivers.oscs.montana.edu (rivers.oscs.montana.edu [192.31.215.70]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA02186 for ; Sat, 25 Mar 1995 22:21:00 -0800 Received: by rivers.oscs.montana.edu (5.65/DEC-Ultrix/4.3) id AA24813; Sat, 25 Mar 1995 23:20:55 -0700 Date: Sat, 25 Mar 1995 23:20:54 -0700 (MST) From: Jason Boerner To: freebsd-ports@FreeBSD.org Subject: uemacs fixes... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ports-owner@FreeBSD.org Precedence: bulk Is there a way to add multiple master_sites? Makfile - MASTER_SITES should be. MASTER_SITES= ftp://midas.mgmt.purdue.edu/dist/uemacs312/ /usr/ports/editors/uemacs/work/src/unix.c Line 311: change the '' to ' '. This would appear to be standard behaviour on the two versions which I have available. I guess that it would be better to have a NOP operator to place here but... NOTE: I recieve a ton of warning messages but they all seem to be non-destructive. I guess if I find a real bug I'll try to fix it. Has anyone had problems? Thanks From owner-freebsd-ports Sat Mar 25 23:56:55 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA03281 for ports-outgoing; Sat, 25 Mar 1995 23:56:55 -0800 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA03275; Sat, 25 Mar 1995 23:56:50 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.9/8.6.9) id XAA01568; Sat, 25 Mar 1995 23:56:42 -0800 Date: Sat, 25 Mar 1995 23:56:42 -0800 Message-Id: <199503260756.XAA01568@silvia.HIP.Berkeley.EDU> To: jmacd@freefall.cdrom.com CC: ports@freefall.cdrom.com In-reply-to: <199503260616.WAA02068@freefall.cdrom.com> (message from Joshua Peck Macdonald on Sat, 25 Mar 1995 22:16:38 -0800) Subject: Re: bsd.port.mk From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * thud-mit-scheme % make "DISTDIR = ../.." * Checksums OK. * ===> Extracting for mit-scheme * tar: can't open archive ../../scheme-microcode+dist-7.3-freebsd.tgz : No such file or directory * tar: child returned status 3 Well, look at this line in bsd.port.mk: if ! (cd ${WRKDIR};${EXTRACT_CMD} ${EXTRACT_BEFORE_ARGS} ${DISTDIR}/$$file ${EXTRACT_AFTER_ARGS});\ The problem is that we've changed bsd.port.mk a while back to have "cd ${WRKDIR}" before "${EXTRACT_CMD}" so that we can use unzip, etc., that doesn't have the equivalent to "-C" in tar. So relative pathnames in DISTDIRs don't work anymore, which was obviously an oversight at that time. You can still use absolute pathnames for alternative DISTDIRs while we figure out how to fix this. Any ideas, anyone? Satoshi