Re: An 'ae' testimony
On Fri, May 21, 1999 at 11:34:24PM -0700, Chris Waters wrote: >"Steve Lamb" <[EMAIL PROTECTED]> writes: >> If ee does this (I dunno, but my friend swears by it), then so be it, >> install it, move on. >Again, ae is *half* the size of ee, and ee doesn't even offer the >option of vi emulation. If we can't fix some of the more noticable >problems of ae, and *still* come in smaller than ee, there's something >wrong with us. I personally *hate* ae. I think it is essential to have some vi-clone installed on the bootdisk or at least ed for the advanced users (so that one can fix e.g. /etc/fstab without cut and paste and grep alone). Of course, an ee (or if you must ae) for the newbies should be there too. David -- Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
Re: intend to package 'country'
On Tue, May 18, 1999 at 12:46:27PM -0700, Joey Hess wrote:
> I have to wonder if we really need a package for this, since grep suffices..
If anyone cares; this is what I use:
function domain { look -f "$1" /usr/share/zoneinfo/iso3166.tab|cut -f2; }
function countrycode { grep "$1" /usr/share/zoneinfo/iso3166.tab|cut -f1; }
David
Re: Which PGP?
On Thu, Oct 15, 1998 at 08:23:38PM +0100, James Troup wrote: >Dave Swegen <[EMAIL PROTECTED]> writes: >> Out of curiosity, which version of PGP is the debian de facto standard. >> I'm currently using v5, but I've seen a number of people use 2.6... >2.x; we don't accept later stuff. Really? I recently retrieved a lot of PGP5-Debian-Devel keys (signed Mailing-List e-Mails, mainly new Developpers), so I got the impression that PGP5 wasn't officially discouraged. This is obviously a problem, since I'm currently using pgp2.62ui which can't verify pgp 5 keys. David
Re: Intent to package: formula and circ
On Tue, Oct 13, 1998 at 06:15:51PM +0200, Andreas Tille wrote: >Furthermore Sebastian Tannert (and me, but the main job has done Sebastian) >developed a package for drawing electrical symbols using TeX. It is >a quite interesting package. It is available at > ftp://ftp.dante.de/tex-archive/macros/generic/diagrams/circ Yes, really nice. >If I look at the TeX-tree of Debian than I notice that there aren't >any packages which could compared with these two. The question is >if this is intended to be so and to ask Thomas Esser to include such >packages into teTeX This would be nice. > or is the only reason for the lack of such >small styles that there wasn't any maintainer for them. I use circ locally, but was to lazy to package it... >In this case I would like to package them. Please do this. David
Re: p3nfs (was Bug #21488: p3nfs linked against libc5)
On Tue, Jun 09, 1998 at 08:35:47PM +0100, Chris Reed wrote: >As listed in The Hamm Bugs Stamp-Out List for 1998-06-08, p3nfs is still >linked against libc5, and the maintainer, [EMAIL PROTECTED] (Billy >C.-M. Chow) cannot be contacted. > >I have looked on ftp.uni-elargen.de:/pub/psion3/local/utilities and found a >glibc diff for version 5.3 (current version in hamm is 5.1). I've >downloaded this and with a one line patch it compiles, and I've had it >working. I did this several weeks ago and tried a upload into frozen/unstable. It got rejected, since new versions aren't accepted... >I would be willing to adopt the package with this new release, but I don't >have a psion permanently; the one I'm using is on loan. I just uploaded a (patched) psion 5.3 [patches from the author himself, a really nice guy] yesterday into unstable. >So, 4 choices: > >i) I do a NMU of the libc6 p3nfs. If it doesn't work, I'd be willing to >look into problems. > >ii) I become maintainer of p3nfs (what is the correct procedure here?), and >then orphan the package when I lose access to a psion. Or even continue >maintaining it, with no idea whether my latest builds work...? You can have the package from me, if you want. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: magicfilter and /etc
On Fri, May 08, 1998 at 08:00:12PM +0200, Andreas Jellinghaus wrote:
> In article <[EMAIL PROTECTED]> you write:
...
> > There are also some other things which really not belong into /etc. For
> >example the Filsystem Hirarchy Standards says that no executable files
> >should go there, but 'filter.ps' and 'filter.pcl' still are executable. In
> >my opinion they should rather go to /usr/lib.
>
> second. if i want to change them, i will copy the file to /etc/magicfilter,
> edit it, and change my printcap to call the new version. someoen should file a
> bug report, or better write a patch...
filter.{ps,pcl} belong to lpr (but I agree about the bug report)
David (magicfilter maintainer)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lists archives outside debian.org
pgpXXqDighaAf.pgp Description: PGP message
Re: /etc/passwd : which software does support this ?
On Wed, 22 Apr 1998 02:41:27 +0200 Remco Blaakmeer wrote: > On 21 Apr 1998, Guy Maor wrote: [at, cron etc and priorities] > I am not really a programer, but I wonder how hard it would be to put > support for these fields in all programs like login, xdm, cron, at and > anything I am forgetting. Could this be done? Sure. It shouldn't be too difficult, since shadow-login is already able to set the values. The only point is not to forget anything. David -- David Frey (B98D36A9) = 51F35923114FC864 7D05FF173C61EFDE Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/passwd : which software does support this ?
On Fri, Apr 17, 1998 at 08:27:39PM +0200, Andreas Jellinghaus wrote: >The comment field is used by various system utilities, >such as finger(1). Three additional values may be present >in the comment field. They are > >pri= - set initial value of nice >umask= - set initial value of umask >ulimit= - set initial value of ulimit > >from passwd(5). what software does support this ? >login, xdm, ssh, cron, at ? shadow-login David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Test Report (was: Re: boot-floppies_2.0.4 (source i386) uploaded)
On Tue, 14 Apr 1998 14:15:19 -0400 Raul Miller wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > > I did hear something about /etc/envronment, but I'm not sure what > > purpose it has and if it works for all shells, etc. [...] > In my opinion, /etc/environment should be supported by init (with a > few sanity checks to avoid wedging the system), login, su, cron, ... shadow-login does support it already (but possibly not enabled)? $tail /etc/login.defs # Should login be allowed if we can't cd to the home directory? # Default in no. # DEFAULT_HOMEyes # # If this file exists and is readable, login environment will be # read from it. Every line should be in the form name=value. # ENVIRON_FILE /etc/environment David -- David Frey (B98D36A9) = 51F35923114FC864 7D05FF173C61EFDE Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dictionary Packages
On Sat, Apr 11, 1998 at 10:23:45PM -0400, Bob Hilliard wrote: > I would like to package these eight dictionaries to accompany > dictd, but if there is a policy against such large text packages, I > could make installer packages to format and install the tarballs that > are available for anonymous ftp from the Dict Group's site. Personally I'd prefer to have additional packages dictd-web1913, dictd-foldoc, dictd-... (depending on dictd), so that I could omit the bible-related stuff on my computer and to have a better granularity. The only drawback, would be that you'd need to write a `dictd-install' script which modifies /etc/dictd.conf. Installer-packages are IMO view a bad idea (but this is from a personal viewpoint): 1. they should only be necessary for non-DFSG software, 2. people with bad connectivity and/or high-priced local telephone companies (e.g. living in Europe :), shouldn't be forced to download 40MB+ software individually. > The largest, and most important, of these dictionaries has a > copyright that is not DFSG compliant. I have been corresponding with > the author, however, and expect to have a version that is DFSG > compliant within a few weeks. Nice! David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I18N (was Re: package pre-selections tool)
On Tue, 07 Apr 1998 08:22:55 -0600 Anthony Fok wrote: > ( ) I18N/L10N (?) -- packages for the world. :-) > * European languages > * Japanese packages (kon2, wnn, emacs20-mule (?), canna, kterm, > doc-jp-linux, etc.) > * Chinese packages (xcin, xfntbig5p-cmex24m, doc-zh-linux, > and in the future: yact, cjklatex, bcs, chdrv, CXWin? etc.) I think, we should try hard to make Debian 2.0 8bit clean and internationalized at least for ``Latin + Cyrillic'' languages per default (no offense to the Asian people intended). So the first point should be obsolete. Then we could offer Japanese/Chinese/Korean/Arab/... languages (with many glyphs and larger space needs) as extra packages. Anyway, what I wanted to say is: internationalization/localization and applications are orthogonal issues. David -- David Frey (B98D36A9) = 51F35923114FC864 7D05FF173C61EFDE Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg's version comparison algorithm?
Hello collegues, I don't understand dpkg's version compare algorithm: ([EMAIL PROTECTED]) /var/debian/unstable/binary-i386/math$dpkg --compare-versions 1.15 lt 1.2-1; echo $? 1 ([EMAIL PROTECTED]) /var/debian/unstable/binary-i386/math$dpkg --compare-versions 1.15 lt 1.20-1; echo $? 0 ([EMAIL PROTECTED]) /var/debian/unstable/binary-i386/math$dpkg --version Debian Linux `dpkg' package management program version 1.4.0.19 (i386 elf). Copyright 1994-1996 Ian Jackson, Bruce Perens. This is free software; see the GNU General Public Licence version 2 or later for copying conditions. There is NO warranty. See dpkg --licence for details. ([EMAIL PROTECTED]) /var/debian/unstable/binary-i386/math$ Why is 1.15 > 1.2 ? Is it necessary to fill in trailing zeroes? David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: driver for Epson Stylus 300
On Tue, Jan 6 1998 12:18 +0100 "Meskes, Michael" writes: > I'm not sure about uniprint but the stcolor driver usage in magicfilter > is outdated, i.e. it uses options no longer avalaible in gs-aladin. Sigh. gs-alladin is in non-free, so magicfilter can't use it. David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake & debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 5 1998 20:08 +0100 Christian Schwarz writes: > > Automake does support the GNU standard, a less restrict one, and (perhaps) > > the gnits standard (the new GNU standard). Will there be automake support > > for Debian packages ? [...] > However, doubts have been presented that it does not fit exactly to > our purposes. Someone would have to do some > experiments on this. If it doesn't fit, we can use or write another macro > generator.) I played over the christmas holidays with autoconf and automake (for use in my rpncalc package). My conclusions: - the generated Makefiles and configure.in's are too strict: e.g. a) they require that the COPYING (GPL) file is present, b) they test whether the cc is gcc (which we already know it is), c) they test whether the libc-headers are ANSI-compliant (which we already know they are) d) they test whether the signal returning type is void (which it is and should be) etc. ad nausaum. Shortly put, most of the test are appropriate for SunOS 4 but not for Debian (GNU libc2, gcc, POSIX.1 and nearly X/OPEN compliant) and are a waste of time. Of course, some m4 guru could put together an Debianized set of autoconf macros... David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Screen-refresh in vi
I have a problem with the vi editor and screen-refresh (and possibly ncurses). Before filing an bug report, I'd like to ask whether somebody noticed this already or whether it is my local configuration problem. Moreover, I'm not able to isolate the offending package. Here it is: You're editing something and want to insert the current date. No, problem, you type: ':r!date' And the problem appears. The screen doesn't get refreshed, until you add something before the line where the output was written to. Neither ^R, nor ^L refresh the whole screen. I have this problem only on my hamm system, the bo system works like a charm. Any ideas/is this already known? ([EMAIL PROTECTED]) /var/tmp$dpkg -s nvi ncurses-base Package: nvi Status: install ok installed Priority: important Section: editors Installed-Size: 385 Maintainer: Steve Greenland <[EMAIL PROTECTED]> Version: 1.79-1 Depends: libc6, ncurses3.4 Conffiles: /etc/rc.boot/nvi 4785743d1b733c9f254d29a28cb299f2 Description: 4.4BSD re-implementation of vi. Vi is the original screen based text editor for Unix systems. It is considered the standard text editor, and is available on almost all Unix systems. . Nvi is intended as a "bug-for-bug compatible" clone of the original BSD vi editor. As such, it doesn't have a lot of snazzy features as do some of the other vi clones such as elvis and vim. However, if all you want is vi, this is the one to get. Package: ncurses-base Essential: yes Status: install ok installed Priority: required Section: base Installed-Size: 47 Maintainer: Galen Hazelwood <[EMAIL PROTECTED]> Source: ncurses Version: 1.9.9g-3 Replaces: ncurses-term Provides: ncurses-runtime Conflicts: ncurses, ncurses-runtime Description: Video terminal manipulation - Minimum terminal emulations This package contains what should be a reasonable subset of terminal definitions, including: ansi, dumb, linux, sun, vt100, vt102, vt220, vt52, xterm and xterm-color. David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Non-interactive installs [Re: need libc5 non-maintainer upgrade]
On Sat, Jan 3 1998 17:38 +0100 Richard Braakman writes: > Christian Schwarz wrote: > [Immediate-Configure: Yes field] [...] > An Immediate-Configure field will help with 2, but I think there is a > better solution. If there is a way to specify that a package's > postinst is _not interactive_, then dpkg can attempt to configure > those packages right away; there is no reason not to try. (If > dependencies are not satisfied, it can try again after all packages > have been unpacked.) [This discussion belongs probably to debian-policy] As Roberto already pointed out on debian-policy, a clever solution would be to make the postinst non-interactive _in general_. If then a program wouldn't have a postconfigure file it could be configured right away. David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Emacs20 and mail file locking.
On Thu, Dec 18 1997 12:16 CST Rob Browning writes: > /* On GNU/Linux systems, both methods are used by various mail > programs. I assume that most people are using newer mailers that > have heard of flock. Change this if you need to. */ > > #define MAIL_USE_FLOCK > > And here's the relevant bit from debian-policy: > > All Debian MUAs and MTAs have to use the `maillock' and `mailunlock' > functions provided by the `liblockfile' packages to lock and unlock > mail boxes. These functions implement a NFS-safe locking mechanism. > (It is ok if MUAs and MTAs don't link against liblockfile but use a > *compatible* mechanism. Please compare the mechanisms very carefully !) > > If emacs' current mechanism *is* compatible, then I could save some > hassle. It isn't. The old policy mandated dot-lock, IIRC. David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: news gateways
On Sun, Dec 14 1997 1:09 GMT [EMAIL PROTECTED] writes: > We should be cognizant that people do troll for mailto: URLs and spam them. This is the real problem IMO with the problem below. > The major problem is that the WWW list archives get into search engines, > and then clueless people search for keywords and fire off questions to > anyone knowledgable that they find. Or much worse: spam the posters with the addresses. I'm getting lately a constant share of UCEs (mostly from the US and Hong Kong), who got their addresses probably from Debian-Lists or the Bug-System. What do the other people do against it? It is annoying, since spam consumes bandwidth and costs me money to download. The upstream ISPs mostly seem unwilling/unable/incompetent to do anything. (if this discussion is inappropriate on debian-devel, move it debian-private) David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [PGP]: can someone in NYC sign me?
On Wed, Dec 10 1997 17:44 GMT Charles Briscoe-Smith writes: > In article <[EMAIL PROTECTED]>, > Alex Yukhimets <[EMAIL PROTECTED]> wrote: > >Just one question to the "public": is it OK to take a floppy with his > >public key, sign it without his phisical presence and than e-mail > >him the signed file back (encripted with his key)? > > Make sure you see some physical identification (driver's licence, > passport or similar). If you know who the person in front of you is, > and he gives you a key, you can check it's his by looking at the ID > on the key and checking the ID's signature. Yes. That's right. > Once you've signed it, there's no reason to encrypt the result. Well, if you're sending him the encrypted key [with the Public key of the person], only the receiver can decrypt it. This is a small trick to insure that the person got the `right key' :) > You could upload it to a keyserver yourself, in fact. Hmm, I wouldn't. It's possible that said person collects more keys and wants to upload them simultaneously. > (I -think- I've understood the issues correctly. Tell me if I'm > wrong, people!) AFAICT you're right. Just my 20 centimes, David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
On Mon, Dec 8 1997 10:58 GMT Philip Hands writes: > <--- == DEL is standard in Linux-land at the moment (very strong argument > for keeping it that way IMHO) This comes from the fact, that the Linux VC is emulating a VT102. David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
OpenBSD-pax (was: Re: Libc6 progress: 1997-12-06)
On Mon, Dec 8 1997 0:49 +0100 Richard Braakman writes: > David Frey wrote: > > On Sat, Dec 6 1997 21:50 +0100 Richard Braakman writes: > > > David Frey <[EMAIL PROTECTED]>: > > > pax-2.1-3(Not DFSG-compliant?) > > > > Hmm. I uploaded pax a few weeks ago into non-free (this was Mark H. Col burn's > > version) > > Let's see... I checked my archives, and I found an upload of pax-2.1-4 > from you dated 13 Sep. Is that the one you mean? > > I suspect that that one was rejected, because it had Distribution: non-fr ee > as well as "* recompiled for libc6". Uploads for the non-free part of > unstable need a Distribution: unstable and a section non-free/foo. Aha. This was it. > This one went to the old non-free. Oops. I didn't intend to do that. Guy, can you delete it, please? (Sorry). > > But anyway, > > if I manage it to compile the Open-BSD pax, we'll have a free pax again! > > Great :) > > What do you want me to put in the comment next to pax? Waiting for the OpenBSD-Version? At the moment, I need to write a fgetln()-Function in order to be able to compile the thing. Does anybody have such a thing handy? David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-06
On Sat, Dec 6 1997 21:50 +0100 Richard Braakman writes: ... > David Frey <[EMAIL PROTECTED]>: > pax-2.1-3(Not DFSG-compliant?) Hmm. I uploaded pax a few weeks ago into non-free (this was Mark H. Colburn's version) But anyway, if I manage it to compile the Open-BSD pax, we'll have a free pax again! David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Next approach: Documentation Policy
On Sun, Jun 29 1997 12:11 +0200 Christian Schwarz writes: > Packages that contain programs with GNU info manuals, should provide > the manuals in HTML _and_ in GNU info format. The HTML files should be Shouldn't this read texinfo? -- > stored in the directory > /usr/doc//html-texi/ David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RfD: Debian is not randomly installing services
> But I thought most people already complain, that there are too many > questions in the installer scripts (postinst). > > What do the others think about this? We probably should ask all questions at the end once? Let dpkg/diety do something like this: 0. The question was already answered during an old install (and stored via dtxtdb or something better) -> take that answer 1a. Otherwise ask all questions at the end of the install. 1b. Better alternative, but I don't know whether this is feasible: Ask the questions at the beginning and configure the package just after install. This is better, since it minimizes the time window of unconfigured packages. This would require dpkg/diety to know what questions which package asks (new config file) David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: End of Documentation Discussion
On Fri, Jun 27 1997 16:10 CDT John Goerzen writes: John, I agree with the overall contents of your remarks. Just some remarks: > * HTML cannot do very much with formatting. [...] > * HTML cannot be easily printed. [...] > * HTML cannot be easily grepped. [...] I fully agree. [...] > I think that other formats have the following problems: > * PostScript makes very nice printed output, but it difficult to >search and requires a fairly expensive graphical monitor to be >able to read on-screen reasonably. And it is generally too large for its contents. > * LaTeX also makes nice printed output and can be converted to >HTML as well as other formats, but such conversion on-the-fly is >not practical due to the huge size of the LaTeX system. And the conversion is generally poor. > * GNU Info has an awkward interface and is difficult to search. >It is also nearly impossible to print an entire manual from the >files in the info directory. This is not meant to be. If you want to print something, convert the .texi files to dvi! > * Manpages are portable, searchable, and produce nice printed ouput >with man -t. However, for very long manuals, they are not >approprriate. I agree. > I would suggest either of the following: > * DVI format. It can be converted to HTML (I think...) and plain Nope, not possible. In DVI you have lost the structure information. >text on-the-fly. It can also be converted to PostScript and >have very nice printed documentation. Yes. >searchable. Downside: conversion to PostScript requires >significant disk resources (fonts!) and can be a lengthy process. >On second thought, maybe DVI isn't the best choice... :-) No. DVI is not font-independent (unfortunately). [...] > All packages should ideally provide manpages (although there are a few > exceptions). Rewrite this to: `All packages provide manpages'. > Packages providing additional documentation should use > GNU info format or LinuxDoc/SGML format. There should be a script or GNU texinfo (in the source package) > program available to convert SGML to HTML on-the-fly (shouldn't be > hard since we already have the tools to do that). Various other > documentation provided by the upstream author should be converted to > SGML if possible; if not, it should be included untouched. Probably yes, although I don't exactly love SGML. > Just to summarize: I believe that HTML is a VERY BAD choice for > unification of documentation for the reasons outlined above. Agreed. David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How about e2compr? Was: fixhrefgz debate
> I won't use killfiles on debian-devel, and I won't ask Christoph > to leave, so I'm leaving debian-devel myself. Given the > temperature of my recent input, it might be just as well, since > I don't seem to be able to write anything but flames. If anything > important happens, I assume I will hear about it sooner or later. Please don't leave. Just since somebody writes incoherent stuff and lowers the SNR it's no reason to loose the intelligent people. David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dc and bc in Important?
On Wed, Jun 25 1997 8:35 PDT Bill Mitchell writes: > On Wed, 25 Jun 1997, David Frey wrote: > > Correlated note: It is not explicitely stated in the policy manual, but > > IMO we should flag all utilities mentioned in the POSIX.2 standard as > > 'Important' [...] > > IMHO, as long as the list is of manageable size, it'd be better to > explicitly list the "important" utilities instead of leaving this > as a judgement call to be made (differently) by each individual > package maintainer. Hmm? I thought to unconditionally mark all packages which include at least one POSIX.2 program with `Important'. I thought the long-term goal of Debian is to get POSIX-branded, so this is in some form a must, isn't it? > One complicating factor here is utility vs. package granularity. > For example: uuencode/uudecode are packaged with sharutils, and > ar with binutils. uuencode/uudecode and ar are on your POSIX > list, but other utilities in the packages which provide them > are not. Yes, I agree. There are 2 possibilities: 1. break out the needed programs if the package is exotic, or 2. (IMO the better method) mark the whole package important. (Comments welcome) David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
why are shared libs chmod +x? (again)
On Sun, Jun 1 1997 21:24 +0200 Christian Schwarz writes: > Can someone tell me why shared libs should be installed executable? > (Actually, Christoph Lameter wants to know this, cf. #7129, but since I > don't know this either I'll redirect the question to this list.) > > This is current policy and I want to add a small note to the paragraph > stating the reasons for this. What was the answer, why shared libraries are mode 755? I'd suggest to revert them back to 644: ([EMAIL PROTECTED]) ~$/lib/libreadline.so.2.1 Segmentation fault (I'd expected a better error message like `no binary' or something like that). David -- David Frey |Linux --- the choice of a GNU generation! 51F35923114FC8647D05FF173C61EFDE|GE C++ UL+++ P- W-- !w--- PGP++ [EMAIL PROTECTED] R D--- e++ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: why are shared libs chmod +x? (again)
(People, please don't unnecessarily Cc:) On Fri, Jun 27 1997 11:03 +0200 joost witteveen writes: > > > > Can someone tell me why shared libs should be installed executable? > > > > (Actually, Christoph Lameter wants to know this, cf. #7129, but since I > > > > don't know this either I'll redirect the question to this list.) > > > > > > > > This is current policy and I want to add a small note to the paragraph > > > > stating the reasons for this. > [..] > > And since we're basically recompiling all the libraries for 2.0, this would > > be a good time to make the change. If no one can provide a good reason for > > libraries being 755, I say we revert them to 644. > > The only reason I remember is that the shared libraries are > "executed", only not from the commandline, but within other binaries. This might be, but the linker doesn't care. (In Debian 1.1 we had the shared libraries 644, IIRC). David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
On Mon, Jun 23 1997 23:08 +0200 Martin Schulze writes: > David Frey writes: > > > > On Mon, Jun 23 1997 7:25 BST Marco Budde writes: > > > Any comments? > > (Please add next time a translated version too, not everyone > > reads natively german [I'd had a hard time to understand e.g. > > dutch or polish]) > > *smile* Some german people have problems understanding swiss people, too. :-) *smile* But only if they live too far in the north. Our Bavarian neighbours don't have this problem at least. >;-) David > / The good thing about standards is / > / that there are so many to choose from. -- Andrew S. Tanenbaum / ^^^ Wasn't this IBM? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
On Mon, Jun 23 1997 22:08 BST James Troup writes: > David Frey <[EMAIL PROTECTED]> writes: > > > > * Das Aendern des Dokuments ist nicht erlaubt. Das gilt sowohl > > >fuer den Inhalt als auch fuer das Dateiformat bzw. die > > >Gestaltung. Auch das Entfernen unliebsamer Passagen ist nicht > > >erlaubt. > > > > Changing is now allowed. This applies to the contents, the file > > format resp. layout. The removing of disagreeable passages is not > > allowed. > > s/now/not/; a rather significant change :-) You're right. I probably was tired about typing so many types '...not allowed to...' (cc'ing to debian-devel for completeness). David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dc and bc in Important?
On Tue, Jun 24 1997 15:52 BST James Troup writes: > John Goerzen <[EMAIL PROTECTED]> writes: > > > It seems to me that dc and bc aren't vital to the workings of a > > system (when I deselect them, dselect doesn't warn about any > > dependencies), yet they are in Important. Why? > > Because they match the first definition of Important in Policy (see > below). When I released my first version of bc/dc I downgraded them > to Optional by mistake and someone complained; that's obviously one > person who agrees with me. Does anyone else think bc/dc should be > downgraded? (If so, why?) > > ``Important programs, including those which one would expect to find > on any Unix-like system. If the expectation is that an experienced > Unix person who found it missing would go `What the F*!@<+ is going > on, where is foo', it should be in important. This is an important > criterion because we are trying to produce, amongst other things, a > free Unix.'' (3.1.4.1 of debian-policy 2.1.3.3) Correlated note: It is not explicitely stated in the policy manual, but IMO we should flag all utilities mentioned in the POSIX.2 standard as 'Important' (or eventually give another label, POSIX.2). These are (I'm listing the commands, not the package. Figuring out which command belongs into which package is left as an exercice for the labeller): (Execution Environment Utilities:) awk, basename, bc, cat, cd, chgrp, chmod, chown, cksum, cmp, comm, command [1], cp, cut, date, dd, diff, dirname, echo, ed, env, expr, false, find, fold, getconf, getopts, grep, head, id, join, kill, ln, locale, localedef, logger, logname, lp [2], ls, mailx, mkdir, mkfifo, mv, nohup, od, paste, pathchk, pax, pr, printf, pwd, read, rm, rmdir, sed, sh, sleep, sort, stty, tail, tee, touch, tr, true, tty, umask, uname, uniq, wait, wc, xargs, (User Portability Utilities) alias, at, batch, bg, crontab, csplit, ctags, df, du, ex, expand, fc, fg, file, jobs, man, mesg, more, newgrp, nice, nm, patch, ps, renice, split, strings, tabs, talk, time, tput, unalias, unexpand, uudecode, uuencode, vi, who, write, (Software Development Utilities) ar, make, strip. [1] bash builtin David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
On Mon, Jun 23 1997 7:25 BST Marco Budde writes: > Any comments? (Please add next time a translated version too, not everyone reads natively german [I'd had a hard time to understand e.g. dutch or polish]) > Copyright > = > > Dieses Dokument ist Freeware im Sinne des Software-Lizenzrechts. Die Regeln > im einzelnen: (My translation is rough) This document is freeware in the sense of software license law. The rules are according to: > * Das Kopieren und Weitergeben des Dokuments ist erlaubt. Copying and giving away of the document is allowed. > * Das Veroeffentlichen auf WWW-Servern, Online-Diensten oder Mailboxen ist >erlaubt. Publishing on WWW-Servers, Online-services or mailboxes is allowed. > * Das Veroeffentlichen auf Datentraegern wie CD-ROMs ist erlaubt, auch >wenn diese Datentraeger kommerziell orientiert sind. Publishing on CD-ROMs is allowed, even if the media is commercially oriented. > * Das Aendern des Dokuments ist nicht erlaubt. Das gilt sowohl fuer den >Inhalt als auch fuer das Dateiformat bzw. die Gestaltung. Auch das >Entfernen unliebsamer Passagen ist nicht erlaubt. Changing is now allowed. This applies to the contents, the file format resp. layout. The removing of disagreeable passages is not allowed. > * Das Dokument muss stets in der vorliegenden Form und vollstaendig kopiert, >weitergegeben oder anderweitig veroefftentlicht werden - das Kopieren, >Weitergeben oder Veroeffentlichen von Teilen des Dokuments ist nicht >erlaubt. Massgeblich hierfuer ist die Download-Datei. The document has always to be copied, given away or published in the given state in full. Copying, giving away or publishing of parts of this document is forbidden. Authorative is the file to download. > * Das Veroeffentlichen des Dokuments auf WWW-Servern oder Datentraegern im >Zusammenhang mit illegalem pornografischem Material oder nazistischem >Gedankengut ist unerwuenscht und wird bei Entdeckung juristisch verfolgt. Publishing this document on WWW-servers or data media in the contents with illegal pornographic material or Nazi-ideology is not desired and will be juristically prosecuted on discovery. (Not a problem for us, David) > Wenn Sie dieses Dokument an einer neuen Stelle im WWW plazieren oder an > anderer Stelle publizieren wollen, besorgen Sie sich das Dokument an einer > der Stellen zum Downloaden. Da das Dokument bereits an so vielen Adressen > im WWW steht, uebernimmt der Autor hierfuer keine Betreuung. If you intend to place/publish this document on a new place in the WWW, get the document at one of the places to download. Since the document is already on so much places on the WWW, the author takes no responsability. > Bei Veroeffentlichung auf CD-ROM oder vergleichbaren Datentraegern ist es > eine feine Geste, dem Autor ein Belegexemplar zukommen zu lassen. Senden > Sie dieses per Post an TeamOne, z.Hd. Stefan Muenz, Kistlerhofstr. 111, > D-81379 Muenchen. If you publish on CD-ROM or aequivalent media it would be nice to send an complimentary exemplary to the author. Send it via mail to: ... Conclusion: only the last paragraph is hairy. David PS: Has somebody found a good online dictionary? (A dictionary e.g. French/English, German/English, not only a word-list) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
(I'm on debian-devel, no need to Cc:) On Sun, Jun 22 1997 15:11 EDT "Colin R. Telmer" writes: > Given this, using chmod to set user or group ID on execution(s) is > useless. It will always run as the uid hardwired in. [...] > The previous maintainer of plan (Christoph Lameter) had a > postinst that created a system user called netplan and then installed the > netplan executable with userid netplan so that when netplan was started at > boot, it ran as user netplan. This version of plan will not allow that do > to the hardwiring above. To my knowledge, there are two ways to get around > this: > > 1) Use an existing uid and gid from the already defined ones in the base >system. > 2) Create a new system user called netplan using specified uid and gid and >then also use this uid and gid to hardwire in during compilation. Here >I would assume that I need to contact the base-system maintainer and >ask for a new uid/gid combination as in the policy manual. > > What should I do? I personally would swallow the bitter pill and ask the base-system maintainer for a specific uid (eventually gid too) for netplan (solution 2). [I still don't understand the motivation behind the hard-wiring of the UIDs; it is IMNSHO a bit of paranoid (I mean, nobody would want to run netplan suid root, would one?)] David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian-Policy Manual
> > David Frey <[EMAIL PROTECTED]> writes:
> > >>TOPIC 4: editor/pager policy
> > > What is the benefit of /usr/bin/sensible-{editor,pager}?
> > > Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> > > if both variables are unset? (auch, don't beat me)
> >
> > That might enable us to get rid of /usr/bin/{editor,pager} though it's an
> > inferior solution to what we're doing at the moment. It won't enable us to
> > get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
> > understand EDITOR and PAGER.
>
> Not exactly.
>
> The files /usr/bin/{editor,pager} will be managed through alternatives.
> Since alternatives can be changed by the sysadmin only, we allow the user
> to define EDITOR and PAGER to override this.
>
> That's why we need "sensible-{editor,pager}". These are two simply shell
> scripts that test if EDITOR/PAGER is set and launches either that program,
> or /usr/bin/{editor,pager}.
Im still confused. What do /usr/bin/{editor,pager} do then?
Are they hard links to vi and more? Or equivalently trivial shell scripts
of the form:
#!/bin/sh
/usr/bin/vi
Thanks for your patience,
David
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Debian-Policy Manual
My comments on Christian's proposal (which is very good, thank you christian):
>TOPIC 1: policy for user and group ids (uids, gids)
Wouldn't it be better to start the user uid range with 100 as most other
Unices do?
>TOPIC 4: editor/pager policy
What is the benefit of /usr/bin/sensible-{editor,pager}?
Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
if both variables are unset? (auch, don't beat me)
>TOPIC 11: policy about including documentation
Ship info as default. Make a -texi from which texi2html can
create html sources.
> - how "large" may doc files be until they are moved into a
> seperate package?
500k?
David
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
On Sun, Jun 15 1997 11:20 BST Philip Hands writes: > > Exim doesn't provide UUCP capabilities *at all*, thus it is rather > > useless for sites that use UUCP (like me). > > I expect that you will admit that UUCP sites are a minority. I use UUCP, but > I don't think that the majority of users who do not should be forced to use a > cumbersome mail transfer agent because of that. As several people already pointed out, the phone costs in Europe are rather high; so that people like to use the transfer agent with the shortest connection duration, which is doubtless UUCP. But this requires an MTA which is capable of bang-paths in the envelope (i.e. the From /MAIL FROM: fields (depending whether you use rmail or rsmtp) [The From: field is nowadays of course a FQDN]. exim should be able to parse simple bang-paths IMO (host!user), since most UUCP paths are nowadays only one hop or two,or this deficiency should be documented in the package (Conflicts: uucp or something like that) [ I agree with the rest of the post about setup-friendliness, complexity and security] David -- David Frey |Linux --- the choice of a GNU generation! 51F35923114FC8647D05FF173C61EFDE|GE C++ UL+++ P- W-- !w--- PGP++ [EMAIL PROTECTED] R D--- e++ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New version of dtxtdb (0.15)
pgp5giZfsgbKh.pgp Description: PGP message
New version of dtxtdb (0.15)
pgpGAtHFNd8a1.pgp Description: PGP message
Version skew between architectures
Hi, Yesterday I got a bug report against dump from someone running Debian on a m68k machine. His problem was that he used the new e2fsprogs, but the old dump binary -12 instead of -14. Question: How do we avoid this sort of problem? How is the compilation for non-Maintainer architectures handled? (I'm not accusing anyone; and it was partly my fault, I should have stated that the dump package -14 depens on ext2fsprogs >= 1.10!) David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc6 policy in unstable
Hello collegues, What is the policy for uploads into unstable regarding libc6? Must all new programs goint into unstable be linked with libc6? David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Some ideas about the text db
Hi Tom, > Basically, we first have a "/default" directory, which every package > imports its default settings into. > > User configuration is put under "/config", which means that the system > will first look under /config, then /default when a variable is requested. I don't see the advantage of this scheme. Please explain why it is favorable to have 2 configuration trees. If you wan't to have 2 trees, a better and easier approach is to have (standard Unix-way) a $HOME/.config/... and a /etc/config/... tree. But the question is, whether you want to use the configuration database for all and everything (-> each user wants his/her own copy) or just for system-related entries (one global /etc/config is enough). David -- David Frey |Linux --- the choice of a GNU generation! 51F35923114FC8647D05FF173C61EFDE|GE C++ UL+++ P- W-- !w--- PGP++ [EMAIL PROTECTED] R D--- e++ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dtextdb uploaded into experimental
pgpZHFB2uUNIM.pgp Description: PGP message
Re: Infocom Games (Was: long list of give away or orphaned packages)
On Sat, May 31 1997 20:15 - [EMAIL PROTECTED] writes: > On Sat, 31 May 1997, Brian White wrote: > > > > None of the Infocom games can be distributed, however. You have to > > buy them. > > Heh. I guess that means we cant package up any of these then > > ftp://ftp.gmd.de/if-archive Sure we can. These are not Infocom games, or, when they are, then they are Infocom sampler packages, which are IMO distributable. Most of if-archive is freeware (written by other people than Infocom, but in the Z-Language). What you of course cannot distribute -- as already mentioned -- are the real Infocom games (Trinity, Zork 1-3 etc.) David PS1: Frotz can AFAIK handle Z8 games PS2: Was anyone able to run `adventure' under Linux? Compiling went ok, but running gave an error about not finding the verb 'abcde' or similar. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GOAL: Consistent Keyboard Configuration
On Mon, May 26 1997 20:40 +0200 Christian Schwarz writes: > Then I have a "special ALT" key on my german kbd, that's label "Alt Gr". > In DOS/Win95 it behaves like pressing Ctrl-Alt together. It's useful to > get some "alt-alt keys" (for example, I have "=", "0", and, "}" on one > key). I think the behaviour should be the same in Debian. AltGr is a special modifier: it is a kind of Hyper key if you want (with Alt == Meta). [lot of agrees about Home/End/cursor block etc.] > What about the second "cursor block" at the right? It would be nice if one > could switch between the function keys (left, right, etc.) and the digits > (0, 1, etc.) with the "Num Lock" key. Is this possible? (The current > behaviour is to produce digits all the time, no matter if "Num Lock" is > set.) Mine work, both under X as under the console too. > Then I have a "Print" key, "Scroll-Lock", and "Pause". All three keys > don't have an effect in my X configuration--on the console "Scroll-Lock" > starts/stops terminal output, just like "C-S and C-Q". Is there any useful > meaning for "Print" and "Pause" in Linux? Yes: they may the registers, task list etc. and may switch from/to the last used console. > Does someone have any other special keys on his keyboard that we should > define? (We'll just do it if the keyboard layout is widely used.) I'm sending you my special Swiss German Keymap and the X additions as a reference what is possible (sorry for the others to bother you with this...) David PS: I was never able to reliably switch the Ctrl/CapsLock key a la Sun. 8<--- # Console keyboard layout # # $Id: sg-latin1.map,v 1.4 1996/11/14 20:08:10 david Exp $ # $Log: sg-latin1.map,v $ # Revision 1.4 1996/11/14 20:08:10 david # Dumped keymap; fixed ^Y/^Z mapping. # charset "iso-8859-1" keycode 1 = Escape Escape alt keycode 1 = Meta_Escape keycode 2 = one plus bar alt keycode 2 = Meta_one keycode 3 = two quotedbl at control keycode 3 = nul shift control keycode 3 = nul alt keycode 3 = Meta_two keycode 4 = threeasterisk numbersign control keycode 4 = Escape alt keycode 4 = Meta_three keycode 5 = four ccedilla dollar control keycode 5 = Control_backslash alt keycode 5 = Meta_four keycode 6 = five percent control keycode 6 = Control_bracketright alt keycode 6 = Meta_five keycode 7 = six ampersandnotsign control keycode 7 = Control_asciicircum alt keycode 7 = Meta_six keycode 8 = sevenslashbar control keycode 8 = Control_underscore alt keycode 8 = Meta_seven keycode 9 = eightparenleftcent control keycode 9 = Delete alt keycode 9 = Meta_eight keycode 10 = nine parenright bracketright alt keycode 10 = Meta_nine keycode 11 = zero equalbraceright alt keycode 11 = Meta_zero keycode 12 = apostrophe question dead_acute control keycode 12 = Control_underscore shift control keycode 12 = Control_underscore alt keycode 12 = Meta_minus keycode 13 = dead_circumflex dead_grave dead_tilde alt keycode 13 = Meta_equal keycode 14 = Delete Delete control keycode 14 = BackSpace alt keycode 14 = Meta_Delete keycode 15 = Tab Tab alt keycode 15 = Meta_Tab keycode 16 = +qQ+q control keycode 16 = Control_q shift control keycode 16 = Control_q alt keycode 16 = Meta_q control alt keycode 16 = Meta_Control_q keycode 17 = +wW+w control keycode 17 = Control_w shift control keycode 17 = Control_w alt keycode 17 = Meta_w control alt keycode 17 = Meta_Control_w keycode 18 = +eEHex_E control keycode 18 = Control_e shift control keycode 18 = Control_e alt keycode 18 = Meta_e control alt keycode 18 = Meta_Control_e keycode 19 = +rRregistered control keycode 19 = Control_r shift control keycode 19 = Control_
Re: Questions (Debian Install)
On Fri, May 23 1997 8:57 PDT David Cary writes:
> I started all over Yet Again, and I think I discovered a bug in my "latex"
> distribution that crashed the default setup (but I have documented a way to
> work around it).
Once (a long time ago with Debian 1.1) I had the problem with
/usr/sbin/mfmake{cmmf,mf}base and with /usr/sbin/texmake*fmt that
they redirected _both_ stdin and stdout of mf resp. tex from/to /dev/null.
The problem was, that that LaTeX (I think) complained about a too old
format file (more than a year old; my latex is now stone old:
Document Class: article 1996/05/26 v1.3r Standard LaTeX document class)
and wanted the user to confirm the installation -- net result: the postinst
doesn't work.
Solution: run the mfmake* and/or texmake*fmt scripts manually or remove
the /dev/null part.
(Ask again, if you don't know what I mean).
> They look OK;
> install.html mentions
> [[
> Extended vs. Expanded Memory
>
> If your system provides both extended and expanded memory, set it so
> that there is as much extended and as little expanded memory as
> possible. Linux requires extended memory and can not use expanded
> memory.
> ]]
> which doesn't make sense to me -- I thought that these options were set up
> via "config.sys" in DOS, *not* the BIOS. (Since Linux doesn't have
> "config.sys", I hope it Does the Right Thing).
Not exactly. Some BIOS allow you to remap some part of the RAM to some
or other places (typically on 4MB machines you can map the 384KB into the
UMA(sp? it's a long time ago, since I knew this really, fortunately :)
. This is done on the motherboard.
(And then in the beginnings of the PCs there were EMS expansion cards,
shudder).
> Whoopsies. I get a "APM BIOS ... Unable to handle kernel NULL pointer
> dereference at virtual address c4e0" message (with lots more
> gibberish).
> ]]]
APM is unfortunately non standardized. If you have your kernel up and running
you may eventually find patches...
> When I gave Linux a 100 MB partition, and installed the default selections
> in the Debian distribution; when I tried that earlier I got
> ..
> Setting up latex (2e-7) ...
> Building new latex format(s) using install-fmt-base(8)
> Rebuilding 'latex' format ...
> seems to take a *long* time.
Seems to be the bug above.
> It hung up for over 30 minutes (!), so I hit control-C which killed it,
> returning me to the 'dselect' menu.
> I go to select, and try to turn off latex ...
> 'dselect' unexpectedly dies, giving a "No space left on device" error and
> leaving me at the # prompt.
Probably /tmp full. (failed postinst output).
> I set the "Bootable" flag on the Linux partition for no good reason.
That's the right thing to do, BTW. Then you can activate the other ``OS''
if you want to do something dangerous which could trash your boot partition.
> "Next: Configure the Base System"
> I take the default "U.S.Keyboard".
> I choose the "US", "Pacific" timezone.
> I am tempted to choose GMT ... but I also want to run other OSes, so I say
> Is your system clock set to GMT ... ? n
Which means that automatic the daylight saving time switch won't work.
> "Setting up smail".
> I dunno -- I was planning on using my modem to connect to my ISP via PPP,
> and that doesn't seem to be any of the options. I guess I should choose
> "(5) No configuration your mail system will be broken and should not be
> used. ... You must... later ... run /usr/sbin/smailconfig ...".
Configure as leaf node.
> I logoff with "exit".
> What is the proper way to shut down ? I've been logging out all active
> shells, then hitting ctrl-alt-delete.
That's perfect, init takes care of powering down safely
(wait until you see a ``System is halted'' or ``System is rebooting''
message before turning the power off)
> The total at the bottom is "76716" (KBytes, I assume).
Yes.
> There's one little bit of weirdness; one line says
> "du: ./proc/129/fd/4: No such file or directory".
/proc is a pseudo filesystem. It doesn't contain real files, `just'
the current state of the processes. Ignore the message.
> Hm; I thought there was some way I could ask Linux where on my hard drive
> the minicom program was; something like
> ls -R minic*
> but that doesn't work
> What is the *nix way to "Find file with name:___" ? I know how to do this
> with the Mac OS and several different Microsoft OSes, it's kinda annoying
> me that I can't do this with Linux.
There are several ways to do this:
1. which minicom
2. locate minicom (if you have a locate database built, e.g find
installed)
3. find / -name minicom -print
Hope my answers are of some help,
David
--
David Frey |Linux --- the choice of a GNU generation!
51F35923114FC8647D05FF173C61EFDE|GE C++ UL+++ P- W-- !w--- PGP++ [EMAIL
PROTECTED] R D--- e++
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
dcfgtool and clones
Hello everybody,
On Sat, May 24 1997 11:40 +0200 Andreas Jellinghaus writes:
> there are three tools : cfgtool (lars wirzenius), nod (winfried
> truemper), dcfgtool (mine). and someone is working on a _real_ tool (all
> three have flaws, and if this way we will get a tool with all good
> features).
With somebody, you meant eventually me, since I asked at the Linux-Kongress
in Wuerzbuerg whether I may upload a dcfgtool clone.
But whether it's a ``real'' tool, is not so sure... . Don't hold your breath.
> as you can see, it's a small text database. so it has nothing, absolutly
> nothing to do with deity - that's a GUI.
agreed.
> then we should :
> a) choose _one_ cfgtool (the current one have big flaws. the new one
> will not have them).
> b) change policy to _not_ allow config information in /etc scripts
> c) change policy to _not_ allow additional debian uniq config files to
> fix b). only the textdb should be used.
> d) think about getting rid of some config files only used by shell
> scripts, and use the textdb instead.
yes.
Lars Wirzenius <[EMAIL PROTECTED]> said:
> Assuming the syntax is simple, and there's no need for complexity, a
> hand-written parser can be lightning fast, and all the time is spent
> in starting the program, and reading the file.
Mine is currently a lex parser and a yacc scanner.
Tom Lees <[EMAIL PROTECTED]> said:
> I know all this. But when will it be finished? What about beta
> versions? Is there a mailing list (other than debian-admintool)?
Finished in about a week (beta version).
Mailing list other than debian-admintool: no
Tom Lees <[EMAIL PROTECTED]> said:
> It would be really cool if we upgraded the packaging system to handle
> configuration integrally (so we can do configuration _BEFORE_ an
> installation, etc.).
Yes. But the tricky part is how to rewrite all the /etc/hosts, /etc/networks,
/etc/uucp/{sys,dial,port,config}, /etc/fstab, /etc/slip.dip etc. files.
I don't have an idea.
> Deity definitely _IS_ the right place for this -
> a GUI to do the configuration with, at the same time as packaging
> control!
I'd prefer a back-end and deity would be the frontend.
Jason Gunthorpe <[EMAIL PROTECTED]> said:
> To allow a GUI to present a usefull view of the config file
> information about each field would have to be known. A short
> description, it's content type, possible range information, etc.
You can store a comment (a la dcfgtool), but the other things are not here.
dtxtdb knows about booleans, ints, floats and strings. That's it.
Andreas Jellinghaus <[EMAIL PROTECTED]> said:
> but : don't discuss it now. someone is working on a realy good textdb/
> cfgtool/however-you-call-it, and i'm sure that he will do the right
> thing. wait till it is released.
Discuss it. I'd appreciate an open discussion.
Andreas Jellinghaus <[EMAIL PROTECTED]> said:
> > Mark Baker:
> > > Having your database seems like a reasonable idea, but it needs
> to be plain > text which might be slow; a db file would be faster but
> I want to be able to > change it in a text editor. As a compromise
> it could use the same system than the sendmail aliases: The user make
> changes in a plain text file (/etc/aliases), but the application
> 'compiles' this file as a db database (/etc/aliases.db)?
A database of some sort (e.g. tsearch dump) would be easy to implement,
but I don't like the idea too much. May be later (OK, statting the text
file first is a viable way in-between).
David
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: GOAL: Consistent Keyboard Configuration
On Sat, May 24 1997 20:51 +0200 Christian Schwarz writes: A agree 110%. > Hi folks! > > I just read the excellent article "Consisten Keyboard Configuration" by > John F. Bunch in the Linux Journal, issue #38. > > It would be nice if we could specify a keyboard configuration in the > Policy Manual. That is: we define how each key should behave in the Debian > system and configure all our packages to apply to this standard. In Debian > 2.0 each key should perform the same action in a program, no matter if you > run it on the console, in an XTerm, or somewhere else (e.g. standalone X > program). > > For example, on my keyboard I can use the up- and down-arrow keys to > scroll in "less" (on the console and in an Xterm), but the PgUp and PgDn > keys only work in the Xterm--not on the console. Huh. I have the opposite problem: The end key doens't work in xterms! xterms are in my experience in this regard pathological (opposed to VCs) David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: which group ?
Hi Christian, > I looked at the dump package and found out that /sbin/dump and > /sbin/restore are in the group tty. Why are they in tty, shouldn't it > be disk ? No. dump/restore wants to be in tty in order to be able to notify the operator that (s)he has to change tapes. The operator has to have disk access, either by being root or being in the disk group. Something like -rwsr-sr-x 1 root disk 38653 May 1 22:44 /sbin/dump -rwsr-sr-x 1 root disk 59125 May 1 22:44 /sbin/restore would be a security disaster, since anybody could backup your system and restore the interesting files (a la /etc/shadow). (if rdump/rrestore didn't exist dump/restore needn't the SUID bit). David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Starting messages should have unique style
>> Hi folks! >> I just discovered that the start up messages of Debian don't have a unique >> style. Some say >> starting daemon xxx ... >> (lower case `s' and dots `...') while others say >> Starting network daemons: xxx >> (upper case `S', colon, no dots) etc. >> >> It would be nice if we had a "style guide" so that the different >> packages could all use the same style. What do you think? >> >Cool, I'm not the only one this bothered. Let's change it. Can >we? Please, please! B-) > Yes, this bothered my too. And, in fact I changed it on my box. That's what I'd like to suggest: echo "Starting :" start-stop-daemon --start --exec daemon1 ; echo -n " daemon1" start-stop-daemon --start --exec daemon2 ; echo -n " daemon2" echo "." (That's what I have now) David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Bug#4530: ld cannot find most shared libraries
>This is (IMO) a bug in the upstream sources. (I'm not sure whether this >is confined to certain directories or not, especially since libc doesn't >have this problem.) This is the way ELF-ld functions at the moment (as far as I understand it). IMO the programmer's manual (chapter 12) should mention that you should install the -dev packages, if you wish to compile something, since the links are only contained in the -dev packages. Ian? David? David
Re: proposal: pseudo source packages
[about xforms_0.81...] >xforms_0.81.tar.gz >xforms_0.81.dsc > >For the first 4 files it's ok. But the latter? Would somebody mind, if >I'd remove the debian/ from xforms_0.81.tar.gz and create a >xforms_0.81.orig.tar.gz and then the diffs for the debian changes only? I'm really against the proposal of pseudo-source packages. If you don't have the source, it's useless to upload an essentially empty *.orig.tar.gz and confuses only potential downloaders. The debian-diff is enough; another possibility would be to write an xforms-install package as it was done with netscape. Then, the people with non-intel architectures would know that the package is useless for them (at the moment) and wouldn't need to download it. David -- David Frey <[EMAIL PROTECTED]> |Microsoft isn't the answer...it's the QUESTION. Schlieren, Switzerland |``No'' is the answer. 51F35923114FC8647D05FF173C61EFDE|Use Debian GNU/Linux!
dpkg-shlibs and soname
Hello Folks, Hi Ray, I'm trying to (re)package rpncalc under the new packaging scheme, but I'm having problems with dpkg-shlibs and/or the sonames. Rpncalc needs the readline library to work, which it links with the name libreadline.so.2.0: ([EMAIL PROTECTED]) ~/C/rpncalc-1.1$ldd rpncalc libm.so.5 => /lib/libm.so.5.0.5 libreadline.so.2.0 => /lib/libreadline.so.2.0 libncurses.so.3.0 => /lib/libncurses.so.3.0 libc.so.5 => /lib/libc.so.5.2.18 But dpkg-shlibs disagrees about the dependency information: ([EMAIL PROTECTED]) ~/C/rpncalc-1.1$dpkg-shlibdeps rpncalc dpkg-shlibdeps: warning: unable to find dependency information for shared library libm (soname 5, path /lib/libm.so.5.0.5, dependency field Depends) dpkg-shlibdeps: warning: unable to find dependency information for shared library libreadline (soname 2.0, path /lib/libreadline.so.2.0, dependency field Depend s) (well the math library linking can be ignored) If dpkg-shlibs looks into the package names, the point is clear: there is no libreadline2.0-package:([EMAIL PROTECTED]) ~/C/rpncalc-1.1$dpkg -s libreadline2 Package: libreadline2 Status: install ok installed Priority: required Section: base Maintainer: Ray Dassen <[EMAIL PROTECTED]> Source: libreadline Version: 2.0-15 Provides: libreadline Depends: libc5 (>= 5.2.16-1), ncurses3.0 (>= 1.9.8a-1) Conflicts: librl (<= 2.0.3-2), libreadline Description: GNU readline and history libraries, runtime versions. Now: What should I do? I see 3 alternatives: 1) Recompile the libreadline package to provide the libreadline2.0 name, 2) link the rpncalc (somehow) against the libreadline2 library (but how?), 3) fool around with the shlibdeps.local file. What is the right thing to do? Thanks in advance for comments, David PS: Debian GNU/Linux dpkg-shlibdeps 1.3.14. -- David Frey <[EMAIL PROTECTED]> |Microsoft isn't the answer...it's the QUESTION. Schlieren, Switzerland |``No'' is the answer. 51F35923114FC8647D05FF173C61EFDE|Use Debian GNU/Linux!
Bug#4346: Essential LaTeX style files missing
> Thomas> In 1.1.7, Debian's TeX is unusable for somebody who wants to do > Thomas> serious work with it, at least for me (I work in German). Hardly > Thomas> any of the often - used packages is there (this starts with a4.sty, > Thomas> which is required by the documentation of german.sty, missing). With \LaTeX2e you shouldn't need A4.sty. Just say a4paper in the \documentclass options. > - if you were to start from Karl Berry's sources, you wouldn't get it >either, what Debian delivers is a standard "base" TeX. Just a silly question: Which flavour of \TeX is Debian shipping? How far is it away from e.g. teTeX? >And Debian is after all an open system. Everybody could package, say, >latex-goodies. I just put these things into /usr/local/lib/texmf/tex/latex // Sidenote: I've packaged some things from teTeX for myself, for example the rsfs fonts, which are badly needed. But: Is somebody knowledgeable on the copyright terms on the rsfs's fonts? >As for a4, I much prefer vmargin (which the LaTeX Companion has as vpage, >described on page 89). And I pagesize... David
Bug#4269: xosview has only XOSView as application resource file
>> Xosview only reads the file XOSView (and ~/.Xdefaults) when evaluating >> its X resources. It does this by doing all the reading by foot (calling >> XrmGetFileDatabase() etc.). >> This is IMO the wrong way to do it; the application should use >> XtGetApplicationResources() (as xsysinfo does it). > >You're absolutely right. > >The upstream maintainer disagrees (well, he agrees, but doesn't want >to change it, AFAIK). Oh, bad news. >do you want me to I do not want you anything :) , but > 1 move xosview to 'contrib', and stop maintaining it > 2 just go on maintaining a broken xosview? i'd vote for 2.
Bug#4269: xosview has only XOSView as application resource file
Package: xosview Version: 1.3.2-6 Xosview only reads the file XOSView (and ~/.Xdefaults) when evaluating its X resources. It does this by doing all the reading by foot (calling XrmGetFileDatabase() etc.). This is IMO the wrong way to do it; the application should use XtGetApplicationResources() (as xsysinfo does it). Using XtGetApplicationResources() makes it possible to have a set of Application-Default-files which can conditionally be used; the classic use of this is to have a 'Foo' and a 'Foo-color' resource file, where 'Foo' contains only black & white stuff and 'Foo-color' contains the color definition and #includes 'Foo'. By doing it this way you can put #ifdef COLOR *customization: -color #endif ... into your /etc/X11/XDefaults line and all (correctly configured) applications look their color configuration up in *-color application definitions. David PS: This bug should probably forwarded to the upstream maintainer. PPS: If I knew enough C++ and if I understood the code dependencies, I had fixed this myself.
Bug#4270: xosview should be able to monitor /dev/ttyS? too
Package: xosview Version: 1.3.2-6 Xosview should be able to monitor the /dev/ttyS* lines too; since nowadays (with the advent of mgetty) a lot of people use /dev/ttyS* for dialout. David
Bug#4156: rpncalc has unexecutable unwriteable /usr/man, /usr/man/man1
In message <[EMAIL PROTECTED]>, Ian Jackson writes: Package: rpncalc Version: 1.1-1 >Directories must be 755 root.root. Fixed in rpncalc-1.1-2
[uploaded to chiark]: dump
I've uploaded to chiark: -BEGIN PGP SIGNED MESSAGE- Date: 07 Aug 96 22:20 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: David Frey <[EMAIL PROTECTED]> Source: dump Version: 0.3-7 Binary: dump Architecture: i386 source Description: dump: Ported 4.4BSD dump and restore utilities. Changes: Fixed permission bug and corrected Architecture field. Files: 467a808a227d9dbb27ed45e6a538c219 99178 admin - dump_0.3-7.tar.gz dac5bd2665a46d59099a1fd048ceb570 3552 admin - dump_0.3-7.diff.gz 463329e7b0701e7bcd66185ad46a9107 63830 admin extra dump_0.3-7_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAwUBMgkXJjeIcrC5jTapAQGrmQQAwPYPkTombzfbpet72kWVpGP8Gqe1y9vC fdZUFzmlm3JR9dnWQ0dETh8RqHBw25BUfbPkSSX2ptZyK3FWcbjEqDWw4kNNC0dE JvkqH5IRJwCzC1+YxQZe03JMuhSW6R5d4PJkebjxMi6LMYTZuVvotN89N79BGrio mNXmeASU1B0= =qc2W -END PGP SIGNATURE- David -- David Frey <[EMAIL PROTECTED]>|Microsoft isn't the answer...it's the QUESTION. Schlieren, Switzerland|``No'' is the answer. PGP-Key available on request |Use Debian GNU/Linux!
Re: Uploading compress-package 1.1 on master
In message <[EMAIL PROTECTED]>, Yves Arrouye writes: >On Aug 4, 6:55pm, David Frey wrote: >} Subject: Re: Uploading compress-package 1.1 on master >} In message <[EMAIL PROTECTED]>, >} [EMAIL PROTECTED] writes: >} >Description: >} > compress-package: fileset to build a Debian compress package > >} compress belongs into non-free, not into devel! >} Reason: Copyright-problems (Unisys-Patent) > >No. This package *is* free: it only allows one to build a compress >binary package, which then will be distributable under Unisys conditions. OK. But isn't the netscape-package in non-free/contrib as well? >BTW, I read in this list that the Unisys patent does not apply outside of >the USA. Is this true? In this case, maybe someone in Europe can make a >binary compress package available? I don't know. [Sidenote (just thinking aloud): Has for example Sun licensed it's compress(1)?] David
Re: Uploading compress-package 1.1 on master
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >Description: > compress-package: fileset to build a Debian compress package >Changes: > * New organization (a la kernel-package) > * Automatic diversion and addition of symlinks for gzip-provided commands > * Can built compress packages from different sources >Files: > fa4c03063df6f2bf96ff8d88129e7bcf 7627 devel - > compress-package_1.1-1.tar.gz > 07b75ae335d55611a52dbb718c58d31f 7804 devel extra > compress-package_1.1-1_all.deb compress belongs into non-free, not into devel! Reason: Copyright-problems (Unisys-Patent) David -- David Frey <[EMAIL PROTECTED]>|Microsoft isn't the answer...it's the QUESTION. Schlieren, Switzerland|``No'' is the answer. PGP-Key available on request |Use Debian GNU/Linux!
