> According to /etc/mh/mtstailor, "lockstyle: 1" apparently means to do the
> correct form of Debian mailbox locking, however `inc' isn't setgid mail so it
> can't create the lock file.
Just sticking in my two cents.
I'm curious as to what changed on Debian to make this a requirement
for mail pr
> However, I remember a discussion that, I believe, lead to this decision; >
I
can't remember all the discussions that have gone on here, there so
very very many. ;-)
> IIRC, it was the same idea that made ae (wrongly) essential - "all other
> editors can be removed, so ae is a better fallbac
> Why is ae the default editor for vipw/vigr even on a completely
> installed system?
>
> Doesn't VI-gr/pw suggest that a VI clone is executed? I can
> understand to use ae as a fallback editor, but not as the main one
Probably it is setup for the same reason ae is the default editor on
the bas
> It's *gnat* , not *gnats*. GNAT is the GNU Ada Translator; GNATS is
> the Problem Report Management System :-)
Right, sorry -- I was coming down off of being wired on expresso and
not thinking/reading/associating very clearly.
> override altogether (perhaps supplying an ada-gcc executable, whi
> Are you sure you don't have another gcc or cc1 in your path? The gcc
> provided in the gcc package knows its own path.
Ah hah! gnats or dpkg seem to be the culprite:
[lestat:~/.www/unabomber/unabomber_writings]$ locate gcc|grep "gcc$"|xargs
file|grep -i exec
/usr/bin/gcc: ELF 32-bit LSB exec
Package: gcc
Maintainer: David Engel <[EMAIL PROTECTED]>
Version: 2.7.2.1-1
I don't know whether or not this is a gcc bug, but after I installed
the latest rex stuff, gcc stopped being able to find cc1. After I
added /usr/lib/gcc-lib/i486-linux/2.7.2.1/ to my path it worked, but I
never needed t
> Its not compiled for 16bpp.
Could such programs then have a note telling us about that in the
description? It looks bad when one downloads software and gets a core
dump trying to run it. I think many people are running 16bpp, and
many more will be running it as 2meg become the default -- is t
Maintainer: Nils Rennebarth <[EMAIL PROTECTED]>
Version: 2.6-2
Provides: kpathsea
Whenever I run dvips or xdvi I get a long list of "Errors" which show
MakeTeXPK trying to create fonts that already exist. I'm really not
sure if this is kpathsea's fault, but it is the one running MakeTeXPK.
I gue
Package: dpkg
Maintainer: Ian Jackson <[EMAIL PROTECTED]>
Version: 1.3.14
I think dpkg may be broken -- when installing dvipsk it seems to
either ignore or eat some files in the deb file. I manually unpacked
the dvipsk.deb file with dpkg-deb --extract, and the config.ps file
was there. Yet whe
Package: amstex
Maintainer: Nils Rennebarth <[EMAIL PROTECTED]>
Version: 2.1-1
one of amstex's file seems to conflict with amsfonts, and it can't
seem to find a tfm file it needs. This is the same error that was
triggering massive multi-megabyte log files before, and I am thinking
that error mig
Package: xypic
Maintainer: Erick Branderhorst <[EMAIL PROTECTED]>
Version: 3.2-4
xypic depends on mflib, yet it seems to overwrite mflib's 1.0.8's
/usr/sbin/install-fmt-base with a different file.
[lestat:/usr/local/pub/debian/tex]# dpkg -i xypic_3.2-4.deb
(Reading database ... 32572 files and
> But you need a list to test it.
Right, but we might want to create "smartlist_tester" to test it.
> Ok. I can ask for it.
Thank you!
> newaliases could only run when the automatic announce list is generated.
Well, my point was that newaliases isn't _on_ my system, and if it
fails the postin
I just had dselect run through the latest and greatest in rex, and
then found out that something in there broke gcc's ability to find
cc1. I just added the directory to my path, and got gcc working
again, but I believe one does not normally need to do this. Gcc
should know where the correct prep
Package: smartlist
Version: 3.10-1
Hello,
I noticed a few problems with the smartlist when I installed it (to
check out whether or not it is a candidate to replace majordumbo)
My first thought was that the postinst should probably ask whether or
not it should set up an announce mailing list --
On Thu, 22 Aug 1996 02:01:47 -0400 I wrote:
< re pppd and slirp
I must have been really tired when I sent this -- I don't know why I
wrote debian-devel in the To: list. Well, nobody responded but I
figured it out anyway. It seems as though problem was likely to come
partly from the kernel not h
If anyone out there has pppd working with slirp, I would surely
appreciate getting a copy of their chat and options file (remember to
edit our the password!).
I've been trying on and off for weeks now, spending 15 minutes trying
to figure out why pppd dials, seems to connect, and then hangs up
Much of this discussion (talking about MS-DOS, assembler code, etc.)
has no real place for debian developers. I've asked Bruce to say
something, and he told me to ask you all to please move this
discussion off the list. Please take it to private e-mail or
something for now.
Jim
> I believe that the 3 first extra explanatory lines in file `xbase.postinst'
> of this package should be removed as they trigger unexpected result in some
> cases (can go into an infinite loop as Xsession will call itself if you
Perhaps the Xsession should be
for i in `grep -v "
> it also runs h2ph in the foreground, when there's no good reason why it
> shouldn't run in the background and let dselect get on with the rest of
> the install process.
Some people don't like this (IMO, very sensible) approach. So there
needs to be options given. What I'm going to do is write
-BEGIN PGP SIGNED MESSAGE-
Date: 30 Jun 96 22:33 UT
Format: 1.5
Distribution: unstable
Priority: Low
Maintainer: Jim Robinson <[EMAIL PROTECTED]>
Source: netpbmdevel
Version: 1994.03.01p1-1
Binary: netpbmdevel
Architecture: i386
Description:
netpbmdevel: Netpbm development libraries a
-BEGIN PGP SIGNED MESSAGE-
Date: 30 Jun 96 22:34 UT
Format: 1.5
Distribution: unstable
Priority: Low
Maintainer: Jim Robinson <[EMAIL PROTECTED]>
Source: netpbm
Version: 1994.03.01p1-1
Binary: netpbm
Architecture: i386 source
Description:
netpbm: netpbm -- graphics conversion tools.
C
-BEGIN PGP SIGNED MESSAGE-
Date: 30 Jun 96 17:56 UT
Format: 1.5
Distribution: unstable
Priority: Low
Maintainer: Jim Robinson <[EMAIL PROTECTED]>
Source: zircon
Version: 1.17p1-1
Binary: zircon
Architecture: i386 source
Description:
zircon: An X11 interface to Internet Relay Chat.
Cha
-BEGIN PGP SIGNED MESSAGE-
Date: 23 Jun 96 22:50 UT
Format: 1.5
Distribution: unstable
Priority: Low
Maintainer: Jim Robinson <[EMAIL PROTECTED]>
Source: auctex
Version: 9.3c-3
Binary: auctex
Architecture: i386 source
Description:
auctex: An integrated environment for writing TeX/LaTe
>
> Package: auctex
> Version: 9.2y-7
>
> The postinst backgrounds itself. How can you tell if it succeeds or
> fails ?
The postinst steps through the tex directories and generates .el code
for auc-tex's use. This process can take a long time on slow
machines.
I decided to background it, and
> How about installing the kernel headers directly in /usr/include,
> rather than linking them into /usr/src? I always assumed this was
> standard kernel practice. Apparently, I was wrong. Are there any
> opinions on the subject?
I doubt it would affect a lot of people. But putting the includ
> Return-Path: <[EMAIL PROTECTED]>
> Tue, 19 Sep 1995 14:31:41 +0200
> Date: Tue, 19 Sep 1995 14:31:41 +0200
> From: [EMAIL PROTECTED] (Sven Rudolph)
> Message-Id: <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Bug#421: unreasonable restriction on term
>
> You
> Dx -- dunno. Didn't take note when I had it open. I grepped
> /var/log/messages for a bogomips figure, but that's apparently
> no longer part of the startup. As I recall under earlier kernels,
> it was low -- perhaps 6.something. Better than the 386 I used
> to run, which was about 4.3.
>
>
> I am considering starting a project which would:
> a) define a standard template for man pages in Linux. I know it would
> appear that one already exists, but it turns out that what really, really
> exists is a good overall description of what should be included in the
> man pages (in /usr/doc/
> Package: irc
>
> The manpage of irc is missing.
The program is IrcII, so:
[lestat:~]$ apropos ircII
ircII (1)- interface to the Internet Relay Chat system
My personal opinion is that apropos should do fuzzy matchs to catch
things like this. :)
Jim
> I'll go further and say that I think that any approach that does not
> include as one of its goals the ability to work with totally virgin source
> archives is a total waste of time because it doesn't buy us enough to
> justify the work.
Now hold on a second there! What about packages put tog
> I completely fail to understand why anyone is promoting this format.
>
> It is ugly, and my format is machine readable too.
But Ian, almost _any_ format can be made machine readable -- but
Bill's format is _easily_ machine readable -- you could slap together
a whole bunch of ways to read it.
> Just out of curiosity, does the following represent a horribly
> formatted and human-unreadable package announcement? Except for
> the lack of a Priority field, it passes the dchanges(1) syntax check.
Very nice! I think it looks quite good. I also happen to like seeing
the MD5SUM and file si
32 matches
Mail list logo
