"Christoph Lameter" <[EMAIL PROTECTED]> writes:
> 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 fo
> "Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
Christian> I just read the excellent article "Consisten Keyboard
Christian> Configuration" by John F. Bunch in the Linux Journal,
Christian> issue #38.
I read it too, and tried some of the configuration given there.
> "Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
Christian> If I remember right someone else posted a Perl example
Christian> for right file locking--but I can't find it.
I did... it's at http://inetarena.com/~karlheg/Public>. I don't
know if it's _really_ the correc
Actually Debian could potentially use all the standard levels 0-6 for
itself, and we could define the not so standard levels 7-9 to be totally
for users purposes. That would give us much more space. We could then
even take one of the 0-6 and reserve it for future use by Debian. And
users would h
[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 UN
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 w
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
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
> > 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
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.
sometime
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 the
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 integra
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
>
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 from
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 ca
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 n
> 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... cut&paste of the actual messa
[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
> > > >
[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
> > > th
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 su
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 al
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?
>
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, the
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?
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.
|
> 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 wh
> 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 mo
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 co
> 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 abou
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: e-m
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 tha
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 whic
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,
> > - 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_
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 LIST:
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 th
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
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
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 troubl
"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?
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
41 matches
Mail list logo
