Sven Rudolph [EMAIL PROTECTED] writes:
Christoph [EMAIL PROTECTED] writes:
On 21 May 1997, John Goerzen wrote:
Since we know of a number of things that have been broken in 2.0.30
(such as IP masquerading being totally hosed), why are we distributing
that version with 1.3?
Boris D. Beletsky [EMAIL PROTECTED] writes:
On 21 May 1997, John Goerzen wrote:
Goerzen Since we know of a number of things that have been broken in
Goerzen 2.0.30 (such as IP masquerading being totally hosed), why
Goerzen are we distributing that version with 1.3? It seems like a
AFAIK
Herbert has fixed bugs in the past in 2.0.30 and the current debian version
is already heavily patched. Its not the question of asking him. He already
did it. The question is if all (dont take all to extremes...) bugs known
have found some consideration by Herbert.
I have not had any
Guy Maor [EMAIL PROTECTED] writes:
Kevin Dalley [EMAIL PROTECTED] writes:
The discussion was whether xemacs-19.14 or 19.15 was the best choice
for bo. Could you please state your reasons for removing xemacs?
Moving 19.15 to bo was out of the question because of the time and the
I was looking at Ian Jackson's automated report of unanswered bugs, and
the number of -very- old bugs is surprising. Closer examination of the
oldest ones makes me think that the problem isn't so much the bugs but
bad handling.
Of the 5 oldest bugs, 4 are on xbase, and might refer to problems
Package: project
Version: 1.3 (?)
I installed, yesterday, what is supposed to become version 1.3. I got
this from ftp.debian.org, downloaded to create a local version on a disk
partition (my connection is via slip, so network installation is
unlikely to succeed).
In general, I must say that
Hi!
This package include a bug to a serious bug in the NIS code of
libc5. It definitely should be part of bo.
Helmut
--
Helmut Geyer[EMAIL PROTECTED]
public PGP key available : finger [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING
- Move config information from install scripts to cfgtool (???)
I'm having a look at ways of doing this. It would be really cool to
integrate this into deity.
there are three tools : cfgtool (lars wirzenius), nod (winfried
truemper), dcfgtool (mine). and someone is working on a _real_ tool
In article [EMAIL PROTECTED],
Andreas Jellinghaus [EMAIL PROTECTED] writes:
b) change policy to _not_ allow config information in /etc scripts
I disagree strongly. A script without config information doesn't belong in
/etc at all.
Having your database seems like a reasonable idea, but
On Sat, 24 May 1997, Mark Baker wrote:
b) change policy to _not_ allow config information in /etc scripts
I disagree strongly. A script without config information doesn't belong in
/etc at all.
Having your database seems like a reasonable idea, but it needs to be plain
text which might
On Sat, 24 May 1997, Vincent Renardias wrote:
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)?
Can you rely on all applications that
hy.
i will write some documentation for some packages i'm maintaining.
i'm no native english speaker, so someone should cross read it. the
problem is not the content, but typos and unclear formulations etc.
any help would be great.
regards, andreas
--
TO UNSUBSCRIBE FROM THIS MAILING LIST:
I was looking at Ian Jackson's automated report of unanswered bugs, and
the number of -very- old bugs is surprising. Closer examination of the
oldest ones makes me think that the problem isn't so much the bugs but
bad handling.
Reminders about bugs older than a certain age (currently about
On 19 Mar 1997 (some time ago), Guy Maor wrote:
I suggested this policy in Jan, and everyone thought it was
reasonable.
Christian - could you add it to your list of proposed policy changes?
I'm currently working on a new policy manual and want to incorporate this.
However, I have two
emacs. While this is an inconvenience, it allows people to choose
their options.
Indeed - I'm the *emacs* maintainer, and I ran xemacs on one of my
systems for a *long* time (finally switched back to emacs for
performance and diskspace reasons, but it was a primary mail reading
site for 6
Of the 5 oldest bugs, 4 are on xbase, and might refer to problems
specific to XFree86 3.1.2, which is no longer current. Someone ought
In fact, when I took over X, I went through and closed a *large*
number of bugs in the database; this also involved writing a bunch of
patches, which is why
On Sat, 24 May 1997, Andreas Jellinghaus wrote:
| hy.
|
| i will write some documentation for some packages i'm maintaining.
| i'm no native english speaker, so someone should cross read it. the
| problem is not the content, but typos and unclear formulations etc.
|
| any help would be great.
|
On 24 May 1997, Mark Eichin wrote:
2200 outstanding bugs. That's 20% of the total bugs received. Can we
at least examine these older bugs and clear them out? Since we have
We get lots of complaints about this. Have you considered instead
putting some *work* into the problem? If
Hi folks!
I'm just working on a new Policy manual and discovered that we don't have
a (working) locking policy right now.
AFAIK, this issue came up two times here on debian-devel (about end of Jan
97 and beginning Feb 97) and was about email folder locking and locking of
/etc/passwd.
AFAIK,
On 21 May 1997, Darren/Torin/Who Ever... wrote:
I have some ideas on what I'm planning on doing with the Debian Perl
package in the near future.
1. Split the main executable and a small set of base files into
perl-base. This would be Priority: required, should it be Essential?
There
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
I've been packaging dotfile generator, and have a small question
related to virtual packages. The package will be multi-binary. It
consists of the main dotfile package, and a number of modules (currently 8). I
want each of the modules to provide a virtual package dotfile-module, but I am
not
[EMAIL PROTECTED] (Buddha Buck) wrote on 23.05.97 in
btWcb1.0.S23.gCSXp@debian:
Dale Scheetz [EMAIL PROTECTED] writes:
This is a continuous problem. I don't know why ftp.debian.org takes so
long to get in sync with master, but the problem simply propogates from
there to all the
[EMAIL PROTECTED] (John Goerzen) wrote on 23.05.97 in [EMAIL PROTECTED]:
Sven Rudolph [EMAIL PROTECTED] writes:
Christoph [EMAIL PROTECTED] writes:
On 21 May 1997, John Goerzen wrote:
Since we know of a number of things that have been broken in 2.0.30
(such as IP masquerading
In dselect, running configure packages multiple times, as suggested in
the documentation, did not seem to correct some of the misinstalled
packages (Xserver, xext).
Please be sure to report these problems specifically, I really am
paying attention to them... cutpaste of the actual messages
Hi,
But can we get consensus on correct behaviour of keys? (the
classic example is the delete-backspace-Control H controversy [for
example, I personally want my backspace to delete character backwards
*all* the time, and not send C-H, and I don't really care about
delete, which would
Hi,
I agree, though I think we can do better than provide a few
example for perl and python -- we could provide a library to do file
locking. (I have a general purpose mutex based class library (I also
have a C implementation) for POSIX and DCE Threads, though I'll have
to see if I
Hi,
Oh, I think that it is not unreasonable to assume that other
packages may depend on this if this becomes the ``official'' method
to handle per user configuration in Debian, so I think that this
definitely qualifies for a discussion here.
Consider this a ``no objections
On Sat, 24 May 1997, Andreas Jellinghaus wrote:
- Move config information from install scripts to cfgtool (???)
I'm having a look at ways of doing this. It would be really cool to
integrate this into deity.
there are three tools : cfgtool (lars wirzenius), nod (winfried
truemper),
On Sat, 24 May 1997, Tom Lees wrote:
as you can see, it's a small text database. so it has nothing, absolutly
nothing to do with deity - that's a GUI.
OK, I should refrase what I wrote.
It would be really cool if we upgraded the packaging system to handle
configuration integrally (so
hy.
tcl and tk should have virtual package names, so a program must not
depend on one tcl package, but can use whatever is present.
of course there can be packages, that will only run with one version of
tcl, so we can provide several tcl and tk packages. but debian native
packages should use
On May 24, Mark Baker wrote
In article [EMAIL PROTECTED],
Andreas Jellinghaus [EMAIL PROTECTED] writes:
b) change policy to _not_ allow config information in /etc scripts
I disagree strongly. A script without config information doesn't belong in
/etc at all.
sometimes you need
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
I just ran across this problem as well. I have a PCI bus
with a DPT RAID board and a 3COM ethernet board trying to
share IRQ 11. There were no software options or hardware
jumpers to change the IRQ selection.
To solve the problem, I moved the ethernet board to a
different empty slot. TA DA! It
Christian Schwarz [EMAIL PROTECTED] writes:
1. Is it allowed to remove these directories in the postrm script? The
first section seams to allow it, but the second paragraph does not allow
it.
2. FSSTND, section 4.8 lists only a few directories. Currently, a few
packages install other
Christian Schwarz [EMAIL PROTECTED] writes:
AFAIK, the only way to lock a file (even reliable over NFS) is to create
another file with a unique filename, e.g. foo.lock-ipaddress-processid,
and create a link say to foo.lock. The link function is atomic per
definition, even via NFS and will
[EMAIL PROTECTED] (Kai Henningsen) writes:
This leaves manual maintenance. I don't know how this is usually handled;
but it doesn't happen very often.
All installs to confirm distributions are manual. Frozen and stable
are confirm, so that's why there are so many errors.
Guy
--
TO
37 matches
Mail list logo
