Decklin Foster writes ("Bug#33993: general: Should log all the boot messages"):
>Cesar Eduardo Barros <[EMAIL PROTECTED]> writes:
>
>> Package: general
>> Version: N/A
>> Severity: wishlist
>>
>> There are too many boot messages, and they sometimes scroll too
>> fast. It would be nice to log all t
Martin Schulze writes ("Re: /usr/etc and /usr/local/etc?"):
>Aaron Van Couwenberghe wrote:
>> Just a quick inquiry --
>>
>> Why is it that we exclude /usr/etc from our distribution? FHS and FSSTND
>
>Because configuration belongs to /etc. Period.
That, and I didn't see /usr/etc listed in the F
Steve Lamb writes ("Re: /opt/ again (was Re: FreeBSD-like approach for Debian?
[was: ...])"):
>Tuesday, September 14, 1999, 11:25:11 PM, Jakob wrote:
>> software. FHS states that /usr must be sharable over a network - e.g. if I
>
>Thank you for finally providing a very good reason for a new to
Sven LUTHER writes ("Re: An 'ae' testimony"):
>On Wed, May 26, 1999 at 02:27:39PM +0200, Josip Rodin wrote:
>> >
>> > Sure this happened to me a long time ago, didn't try ae since because of it
>> > though.
>>
>> One question: how can you blame ae for not working, when you rely on
>> outdated inf
Antti-Juhani Kaijanaho writes ("Re: (LONG) Correct non-US solution"):
>On Tue, May 18, 1999 at 12:20:35PM +0100, Philip Hands wrote:
>> Perhaps a better goal (although significantly more difficult) would be
>> to design a system where we can have multiple symmetric masters, where
>> you can upload
Christopher J. Fearnley writes ("Re: Serious performance bug in Perl"):
>to call it (instead of the default perl - 5.004.04-6). Performance
>improved several hundred-fold. So I believe the problem is either in
>perl or libc6.
>
>Any suggestions on how to resolve this? As I said before the slowdo
Michael Dietrich writes ("Re: xanim on alpha"):
>> Oops. I forgot to remove that evil archive from the source!
>> Technically, we are not allowed to distrbute those. The xanim
>> author got a permission to distribute them, but it's
>> non-transferable. I tried to contact the company that owns th
>Above all i'd like to officially provide my own original package
>"equivs-1.0.3", which is a dummy package used to circumvent dpkg's
>sometimes completely undesired dependency complaints. I made this
>package because i preferred to install and maintain a teTeX tree
>different from the official Deb
>Exactly. So there is no problem when using web-servers.
Umm, yes, there is. I don't want a server running on my machine for
*security* reasons (and one of the places I put debian machines has a
site policy against running http servers). I have enough problems
with security, denial of service at
>I would suggest either of the following:
> * DVI format. It can be converted to HTML (I think...) and plain
> text on-the-fly.
The conversions of DVI->HTML and DVI->Text produce results that range
from poor to completely unusable.
> * LinuxDoc/SGML. This is probably the best choice. It co
>I think we should also consider switching to Maildir/ format for mail drops,
>since it seems to be the only way for delivering mail securely over NFS.
I think we should try to stick with solutions that work with both
Maildir and central spool directories, since otherwise it is difficult
to maint
>BTW, why does runlevel 6 mean reboot? Can't it be runlevel 9? It (6)
>seems to be the standard in Linux boxen now, but why?
AFAIK, it is 6 for reboot since that is what most othe SysV-ish Unixen
use (like Irix and Solaris)
--
Richard W Kaszeta Graduate Student/Sysadmin
[
Package: xanim
Version: 2.70.6.3-3
xanim installs the indeo.readme.gz, creative.readme.gz,
and cinepak.readme.gz files as 600.
--
Richard W Kaszeta Graduate Student/Sysadmin
[EMAIL PROTECTED] University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta
>> Another possibility would be to have a script that runs immediately when
>> you select the package using "dselect", before the package is unpacked, and
>> squirrels away your input for later. Of course, we'd have to run it from
>> "dpkg" if "dselect" was not used.
>>
>> Discussion, please?
>
>I
>The same problem occurs using Slackware and RedHat Linux and on
>different hardware.
Would you be willing to try another amd package? To solve local
problems here I hand-patched a few things in the amd package, and
rolled in a few other patched from various newsgroups, and it has
worked withou
>I created an LPRng package for Debian. LPRng is an enhanced BSD-like
>print spooler and is nearly compatible. (It is available at
>ftp://iona.ie/pub/plp/LPRng/ ).
>
>I'm thinking of obsoleting the lpr package by LPRng.
>Cons:
>- minor incompatibility (needs addditional flag in printcap for
> pri
>I sort of thought we had settled on (a). Although I would normally
>expect /usr/*local* to be local, I don't see any reason not to be
>friendly to unusual setups especially in the case of (c) where it
>doesn't cost anything, assuming the base package puts in a reasonable
>default.
Well, in my ca
Package: emacs-el
Version: 19.34-1
It appears that some of the lisp files included in emacs-19.34-1
and emacs-el 19.34-1 differ from the official distribution.
emacs*deb were download from ftp.debian.org at 9 pm CDT.
emacs-19.34.tar.gz was obtain from prep.ai.mit.edu at 9:30 CDT.
For an example
Just an idea, no flames, etc intended:
Could maintainers who have packages that create directories/etc in
/usr/local make sure they do it in a way that is friendly to
nfs-mounted /usr/local?
Example:
On all of our debian 1.1 machines, /usr/local is an nfs mounted
directory, and on all but one of
>I think having PPP and SLIP work out of the box would be a better use of the
>space.
Personally, I'd vote for vi before slip and ppp. I still can't
believe the number of problems I've had with ae (having trusted it
since it decided I wanted ^Ms in my doc), and how annoying it
is the number of ti
>These problems with the unpacked (preinstalled configured) latex (and
>related) packages has been noticed earlier but was never dealed with.
>Anyone having a mail adress at hand for contacting the latex3 team?
The 'Latex3 Home Page',
http://homepage.cistron.nl/~jlbraams/ltx3/latex3.html,
says th
Latex_2e-7 keeps a set of preload files in both /etc and
/usr/lib/texmf/tex/latex/config, both identical filesets. One of
these should be eliminated.
--
Richard W Kaszeta Graduate Student/Sysadmin
[EMAIL PROTECTED] University of MN, ME Dept
http://www.
Many of the latex package's files contain these lines (these
particular copied from preload.dc in latex_2e-7.deb):
%% IMPORTANT NOTICE:
%% You are not allowed to distribute this file.
%% For distribution of the original source see
%% the copyright notice in the file preload.dtx .
I see nothing in
>Cc: debian-devel@lists.debian.org (Debian Development)
>
>Bruce Perens writes:
>>
>> Let's plan on having "shadow" be part of the base for 1.2 . We should thus
>> have the default "login" be aware of it, etc.
>
>But the question remains, which login? The standard one patched, or the
>shadow one,
Package: latex
Version: 2e-7
The following input file fails with a 'cannot find dc1000.mf' error
\documentclass{article}
\usepackage[T1]{fontenc}
\begin{document}
Testing \LaTeX\ and trying to figure out font encodings.
\end{document}
Versions of my TeX installation:
ii kpathsea2.6-2
>Shouldn't the "paper size" be an attribute of a print queue, and not an
>attribute of a machine?
Paper size effect more that just printers. Previewers and tex tools
come to mind, there may be others...
All I know is right now I've got to tweak quite a few things on a
standard debian 1.1 system
>One could introduce another virtual package (e.g., local-mail), have sendmail
>depend on this. Both procmail and deliver could provide this package. Sounds
>like a bit of an overkill for this problem, though.
Umm, no. There are many ways of configuring sendmail, and a number of
these (includin
Package: hyperlatex
Version: 1.4pl2-0
the included conversion script ps2gif incorrectly references the
directory /usr/local/lib/ghostscript.
--
Richard W Kaszeta Graduate Student/Sysadmin
[EMAIL PROTECTED] University of MN, ME Dept
http://www.menet.umn
>It's the RedHat Package Manager. They would be interested in collaborating
>with us, according to [EMAIL PROTECTED] . We've been a bit too busy bringing
>out the system to get to that, though.
That would be fairly interesting... 'glint' and a few of their other
maintenance toolss seem to have a f
29 matches
Mail list logo
