Just picking a nit.
On Mon, 23 Jun 1997, Brian C. White wrote:
> [...](cu stands for "callout", and is taken from SunOS).
> [...] -- Theodore Ts'o <[EMAIL PROTECTED]>
Unless I'm mistaken (which has happened on occasion),
cu stands for "call unix" a
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White <[EMAIL PROTECTED]>
This document was last modified at Time-stam
On Wed, 18 Jun 1997, Charles Briscoe-Smith wrote:
> How about this: Have the policy dictate that no packages may be
> compiled against libc4/5, and then move any packages that don't comply
> with the policy to 'contrib'. I believe that one of the reasons for
> having 'contrib' is to contain packa
Santiago Vila Doncel <[EMAIL PROTECTED]> wrote:
>On Mon, 16 Jun 1997, Brian C. White wrote:
>
>> August 31, 1997 All packages depending on libc4 or libc5 will be removed.
>
>This is too much strong. I would suggest to make their associated bug
>(the one saying "it's still libc5") "almost-critical"
-BEGIN PGP SIGNED MESSAGE-
On Mon, 16 Jun 1997, Brian C. White wrote:
> August 31, 1997 All packages depending on libc4 or libc5 will be removed.
This is too much strong. I would suggest to make their associated bug
(the one saying "it's still libc5") "almost-critical" instead.
-BEG
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White <[EMAIL PROTECTED]>
This document was last modified at Time-stam
[EMAIL PROTECTED] (Tom Lees) wrote on 09.06.97 in <[EMAIL PROTECTED]>:
Well, it looks as we will have to agree to disagree.
> The file is not modified locally per s.e., just written locally in a
Uh, there's no dots in "per se". That's latin for by or in itself - per is
by, and se is self.
M
On 7 Jun 1997, Kai Henningsen wrote:
> > > Or maybe you have forgotten how conffiles are actually handled:
> > >
> > > (old=original install, new=this install, current=possibly edited version)
> > >
> > > If old md5 = new md5, ignore new file (package unchanged)
> > > If old md5 = curren
[EMAIL PROTECTED] (Tom Lees) wrote on 02.06.97 in <[EMAIL PROTECTED]>:
> On 30 May 1997, Kai Henningsen wrote:
>
> > [EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in
> > <[EMAIL PROTECTED]>:
> >
> > > There are ways to avoid this. For example, modify dpkg not to include
> > > any line with "con
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White <[EMAIL PROTECTED]>
This document was last modified at Time-stam
On 30 May 1997, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in <[EMAIL PROTECTED]>:
>
> > There are ways to avoid this. For example, modify dpkg not to include any
> > line with "config=yes" in it in the md5sum of certain files.
>
> This is a troll, right?
Wrong.
>
On May 26, Brian C. White wrote
> Hamm (Debian 2.0)
Some more ideas/goals:
* PAM-mify at least the essential authentication programs (passwd, su,...)
and preferably all programs that require authentication (POP clients,
webservers, ...).
http://parc.power.net/morgan/Linux-PAM/>.
From th
According to Yann Dirson:
> That just go fine, until you try to use 'halt' or 'reboot': as
> specified in the manpage (yes :), these only call shutdown when in
> runlevel 1-5. Quite strange IMHO. *BE CAREFUL* trying to reproduce it,
> it (probably among other unclean things) doesn't unmount cleanly
Yann Dirson writes:
> * that's not complete either. As already mentionned, the manpage tells
> about undocumented runlevels 7-9. It also poorly tells about those
> AaBbCc I never really understood.
I just tried those runlevels 7-9, with sysvinit_2.71-2. It just need
few modifications to have th
[EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in <[EMAIL PROTECTED]>:
> There are ways to avoid this. For example, modify dpkg not to include any
> line with "config=yes" in it in the md5sum of certain files.
This is a troll, right?
Or maybe you have forgotten how conffiles are actually handle
On Sun, 25 May 1997, Christian Hudon wrote:
> --5mCyUwZo2JvN/JJP
> Content-Type: text/plain; charset=us-ascii
>
> On May 24, Tom Lees wrote
> >
> > The third solution, which I prefer is a utility which modifies the
> > variables within the scripts - it's faster, it is more "backwards
> > compati
On Sun, 25 May 1997, Mark Baker wrote:
> In article <[EMAIL PROTECTED]>,
> Tom Lees <[EMAIL PROTECTED]> writes:
>
> >> the other solution is to have a small utility that stores these values,
> >> can change them and gives the values to the scripts.
> >
> > The third solution, which I pref
Alexander Koch writes:
> ~ # init
> Usage: init 0123456SsQqAaBbCc
>
> 1 is already multiuser, no networking (iirc).
> single-user is S or s (just like using the single as argument for lilo)!
> 2 is networking (basic, inn comes up etc)
> 3 is full networking (whatever you desire)
> 4 and 5
>Bo is currently a "release candidate". It will become an official release
>as soon as the testing group okays it.
What about Bug #10165? Is not being able to boot after an upgrade
critical?
--
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line
This was incorrect...
> *** ***
> *** Release of Bo is HOLDING for CRITICAL BUGS!***
> *** ***
> *** There is one remaining critical bug that must
David Welton <[EMAIL PROTECTED]> writes:
>
> I suppose it really isn't my place to say this, but would it not be
> possible to fix a few of the cosmetic bugs while we are waiting? A few
> that come to mind are the Pacific/Pacific-New conflict in timezone, which
> is going to chalk up 1 bug in th
On 27 May 1997, Mark Eichin wrote:
| while it would be interesting to perhaps do a 1.3.1 or a 1.4 with
| other features, there has to be pressure against doing anything to 1.3
| other than what qa wants to do to get it out the door. We can't make
| every release perfect; in fact, we can't make *a
[EMAIL PROTECTED] (Andreas Jellinghaus) wrote on 27.05.97 in <[EMAIL
PROTECTED]>:
> On May 26, Kai Henningsen wrote
> > [EMAIL PROTECTED] (Vadim Vygonets) wrote on 26.05.97 in
> > <[EMAIL PROTECTED]>:
> >
> > > BTW, why does runlevel 6 mean reboot? Can't it be runlevel 9? It (6)
> > > seems t
while it would be interesting to perhaps do a 1.3.1 or a 1.4 with
other features, there has to be pressure against doing anything to 1.3
other than what qa wants to do to get it out the door. We can't make
every release perfect; in fact, we can't make *any* release
perfect... but we can try to set
On Mon, 26 May 1997, Brian C. White wrote:
| *** ***
| *** Release of Bo is HOLDING for CRITICAL BUGS!***
| *** ***
| *** There is one remaining c
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White <[EMAIL PROTECTED]>
This document was last modified at Time-stam
On May 26, Tom Lees wrote
>
> No, we don't need xdm in runlevel 4. A better solution would be this (but
> it is more difficult, requires multiple inetd.conf files):-
>
> 2: multiuser, minimal networking, no networking daemons (including inetd).
> 3: multiuser, "client" networking (rpc.ugidd, iden
[EMAIL PROTECTED] (Vadim Vygonets) wrote on 26.05.97 in <[EMAIL PROTECTED]>:
> 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?
It's been standard in runlevel-based Unix for a long time. That's probably
because tradi
>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
[
On Mon, 26 May 1997 [EMAIL PROTECTED] wrote:
> 6: reboot
> 7-9: do whatever the heck you want with.
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?
Vadik.
--
Vadim Vygonets * [EMAIL PROTECTED] * [EMAIL PROTECTED] * Uni
On Mon, 26 May 1997, Tom Lees wrote:
> > I'd like something similar to:
> > 1: single user
> > 2: multiuser with minimal networking, probably without offering services
> > 3: full networking (NFS, xfs, anonymous ftp, ...)
> > 4: xdm? (yes, it is common on Slackware and RedHat to start xdm
> >ac
On 23 May 1997, Milan Zamazal wrote:
> I know nothing about runlevel standards, just my opinions:
Same here.
> > "AK" == Alexander Koch <[EMAIL PROTECTED]> writes:
>
> AK: level 1 is without net, 2 is with it all (imo including nfs
> AK: and the like) and 3 is xdm, 6 was shutdown or
On May 24, Tom Lees wrote
>
> The third solution, which I prefer is a utility which modifies the
> variables within the scripts - it's faster, it is more "backwards
> compatible" with sysadmins from other Unices, and generally it's nicer
> (less dependant on the cfgtool at boot-time).
And it chan
In article <[EMAIL PROTECTED]>,
Tom Lees <[EMAIL PROTECTED]> writes:
>> the other solution is to have a small utility that stores these values,
>> can change them and gives the values to the scripts.
>
> The third solution, which I prefer is a utility which modifies the
> variables with
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
> > 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
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
>
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_
On Mon, 19 May 1997, Brian C. White wrote:
> Hamm
>
I think its been agreed that this will be called "Debian 2.0", so why not
add this here.
> * All packages are in the new package format.
Possibly a new source package format may be created, so we should resolve
this before putting too mu
I know nothing about runlevel standards, just my opinions:
> "AK" == Alexander Koch <[EMAIL PROTECTED]> writes:
AK: level 1 is without net, 2 is with it all (imo including nfs
AK: and the like) and 3 is xdm, 6 was shutdown or halt or
AK: whatsoever. at least that i remember from
Apparently this has been fixed:
Login as anonymous...
Setting transfer mode to binary...
Cd to /debian...
getting: frozen/binary-i386/mail/smartlist_3.10-16.deb (78216)
getting: frozen/binary-i386/mail/procmail_3.10.4-2.deb (112164)
getting: frozen/binary-i386/base/modconf_0.2.10.deb (17576)
Proc
Hi,
please note that the Package.gz file and the actual content of frozen
is still inconsistent in at least two points:
getting: frozen/binary-i386/admin/boot-floppies_1.2.17.deb (136652)
frozen/binary-i386/admin/boot-floppies_1.2.17.deb: No such file OR directory.
getting: frozen/binary-i386/ba
[EMAIL PROTECTED] (Brian C. White) writes:
> *** ***
> *** Release of Bo is HOLDING for CRITICAL BUGS!***
> *** ***
> *** There is one remaining c
Did anyone make sure that this is really a bug? In all my testing I did
not encounter this. The upgrade I did yesterday did not show anything.
Reputation: We are just confirming our bad reputation in not being able to
get things out of the door...
There are still nasty bugs in bo that will probab
Christoph Lameter <[EMAIL PROTECTED]> writes:
> Have a look at the bug report. I dont know why no one has marked it as
> done yet. There is a file lists in the but report ending in .dpkg-tmp
> evidently from a crash. Dont be buerocratic about releasing 1.3.
Brian should resist releasing 1.3 if a
Gregor Hoffleit wrote:
>
> > Include the multi-thread support patch for the Objective-C runtime lib (???)
>
> bo includes gstep-base-0.2.12 and gstep-base-0.2.12 includes a patch file
> gcc-2.7.2.1-objc.diff, which therefore should be applied to the gcc in bo
> (the patch applies fine to gcc-2.7.
Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> The remaining question the thread model to be enabled in the patched objc
> runtime. The patched runtime can be compiled for e.g. PCthreads,
> LinuxThreads or no threads at all. Who is to decide this ?
As I understand it, Debian is trying to stand
> Include the multi-thread support patch for the Objective-C runtime lib (???)
According to Scott Christley <[EMAIL PROTECTED]> (de-facto
maintainer of the gcc Objective-C runtime), the Objective-C runtime should
be kept in sync with the gstep-base included in the release.
bo includes gstep-b
Have a look at the bug report. I dont know why no one has marked it as
done yet. There is a file lists in the but report ending in .dpkg-tmp
evidently from a crash. Dont be buerocratic about releasing 1.3.
On Tue, 20 May 1997, Brian White wrote:
>> > ***
> > *** ***
> > *** Release of Bo is HOLDING for CRITICAL BUGS!***
> > *** ***
> > *** There is one remaining critical bug that must be resolved be
In your email to me, Christoph, you wrote:
>
> >
> > *** ***
> > *** Release of Bo is HOLDING for CRITICAL BUGS!***
> > *** ***
> > *** There is
>
> *** ***
> *** Release of Bo is HOLDING for CRITICAL BUGS!***
> *** ***
> *** There is one remaining critical bug that must be resolved before
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White <[EMAIL PROTECTED]>
This document was last modified at Time-stam
58 matches
Mail list logo
