At 10:57 +1100 2000-03-12, Hamish Moffatt wrote:
Also, libc6 tries to restart some NSS-using services, but never seems
to succeed in restarting sshd. I end up with it refusing connections,
although sshd still appears to be running (the original process and
not a new one).
I guess that means that
On Sat, Mar 11, 2000 at 08:10:07PM -0500, Daniel Burrows wrote:
On Sat, Mar 11, 2000 at 08:32:07PM -0400, Nicolás Lichtmaier was heard to say:
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be documented in the
Release Notes.
Why don't we make the new perls conflict the old apt?
And/or make the new Perl pre-depend on the new apt, so the apt update
will happen before anything else?
On Sat, 11 Mar 2000, Nicolás Lichtmaier wrote:
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be
On Sat, Mar 11, 2000 at 08:32:07PM -0400, Nicolás Lichtmaier was heard to say:
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be documented in the
Release Notes.
Why don't we make the new perls
On Sat, 11 Mar 2000, [iso-8859-1] Nicolás Lichtmaier wrote:
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be documented in the
Release Notes.
Why don't we make the new perls conflict the old apt?
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be documented in the
Release Notes.
Why don't we make the new perls conflict the old apt?
Augh, no don't do that!
Upgrading APT will have
I just considered upgrading a slink server here to potato. I
apt-get updated and then ran apt-get dist-upgrade.
exim is held back, because libopenldap1 is uninstallable,
because libopenldap-runtime is uninstallable, because debconf
is uninstallable, because perl-5.004* is to be installed
rather
Le Sat, Mar 11, 2000 at 07:06:24PM +1100, Hamish Moffatt écrivait:
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be documented in the
Release Notes.
Cheers,
--
Raphaël Hertzog -=-
On Sat, Mar 11, 2000 at 04:37:11PM +0100, Raphael Hertzog was heard to say:
Le Sat, Mar 11, 2000 at 07:06:24PM +1100, Hamish Moffatt écrivait:
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be documented
On Sat, Mar 11, 2000 at 04:37:11PM +0100, Raphael Hertzog wrote:
Le Sat, Mar 11, 2000 at 07:06:24PM +1100, Hamish Moffatt écrivait:
Trouble ahead?
Please run apt-get install apt before doing the dist-upgrade. Old apt
don't manage well the perl transition. This will be documented in the
On Sun, Oct 03, 1999 at 09:57:12AM -0400, Raul Miller wrote:
As far as I know, leaving inetd accepting connections would,
worst case, fail -- which is no different from having the service
disabled. In other words, I don't see that disabling the daemon
solves anything useful.
On Mon, Oct
On Sun, Oct 03, 1999 at 07:06:10PM -0400, Raul Miller wrote:
On Mon, Oct 04, 1999 at 08:15:54AM +1000, Herbert Xu wrote:
I think the worst case would be a telnetd linked with a broken
shlib (or in the case of telnetd, perhaps a missing or broken
/usr/lib/telnetd/login) that gives a
On Mon, Oct 04, 1999 at 08:15:54AM +1000, Herbert Xu wrote:
I think the worst case would be a telnetd linked with a broken
shlib (or in the case of telnetd, perhaps a missing or broken
/usr/lib/telnetd/login) that gives a security hole. If you wish
to minimise downtime, the proper way
On Mon, 4 Oct 1999, Herbert Xu wrote:
On Sun, Oct 03, 1999 at 07:06:10PM -0400, Raul Miller wrote:
On Mon, Oct 04, 1999 at 08:15:54AM +1000, Herbert Xu wrote:
I think the worst case would be a telnetd linked with a broken
shlib (or in the case of telnetd, perhaps a missing or broken
As for the discussion, APT actually has such a feature cleverly
undocumented and unmentioned - if you flag a package as Impotant: then
its downtime is minizimized by the ordering code.
Speaking of ordering, there's some bad catch 22 happening when you
deinstall a bunch of packages at the same
On Mon, 4 Oct 1999, Yves Arrouye wrote:
As for the discussion, APT actually has such a feature cleverly
undocumented and unmentioned - if you flag a package as Impotant: then
its downtime is minizimized by the ordering code.
packages that conflict with them. An example is moving from the
On Sat, 2 Oct 1999, Herbert Xu wrote:
If anyone has seen an existing connection die, please report that as a bug.
what against? internet ??
The issue is more about connectivity stability.
Michael Beattie ([EMAIL PROTECTED])
On Mon, Oct 04, 1999 at 09:36:36PM +1300, Michael Beattie wrote:
On Sat, 2 Oct 1999, Herbert Xu wrote:
If anyone has seen an existing connection die, please report that as a bug.
what against? internet ??
My message was about telnetd getting killed, so of course it would be against
packages that conflict with them. An example is moving from the 1.1.2
KDE packages to the 2.0 ones, eg. from kdebase to kdebase-cvs etc. USing
dselect and APT, what happens is that somehow installation of the new
packages is tried first, and fails, and then deinstallation does not
On Sun, Oct 03, 1999 at 08:56:23AM +1000, Herbert Xu wrote:
The idea is that when you upgrade the package like telnetd, there
may be new shlib dependencies, etc. which means that you should stop
spawning new daemons until it is configured. Of course, this may
not happen for every release, but
On Sun, Oct 03, 1999 at 09:57:12AM -0400, Raul Miller wrote:
As far as I know, leaving inetd accepting connections would, worst case,
fail -- which is no different from having the service disabled. In other
words, I don't see that disabling the daemon solves anything useful.
I think the
John Lapeyre [EMAIL PROTECTED] wrote:
Something I have noticed several times. If you are doing a remote upgrade
(probably a crazy idea), the telnet daemon (maybe inetd or something) becomes
unavailble for quite some time. Maybe it is between the time that netbase is
unpacked and when it
On Fri, Oct 01, 1999 at 11:43:17AM -0700, John Lapeyre wrote:
Something I have noticed several times. If you are doing a remote
upgrade (probably a crazy idea), the telnet daemon (maybe inetd or
something) becomes unavailble for quite some time. Maybe it is between the
time that netbase is
On Fri, Oct 01, 1999 at 11:43:17AM -0700, John Lapeyre wrote:
Something I have noticed several times. If you are doing a remote
upgrade (probably a crazy idea), the telnet daemon (maybe inetd or
something) becomes unavailble for quite some time.
netbase restarts inetd in it's postinst,
On Sat, Oct 02, 1999 at 10:26:52PM +1000, Anthony Towns wrote:
Ah. Your problem is probably telnetd's prerm:
] if command -v update-inetd /dev/null 21; then
]update-inetd --disable telnet
] fi
It might be better to bracket this with an `if [ $1 != upgrade ]', or
similar.
On Sat, Oct 02, 1999 at 10:35:10PM +1000, Herbert Xu wrote:
No, during the upgrade, inetd should not try to start new copies of telnetd
because it may not be there or it may not be executable (e.g., shlibs that
it depends on may be missing). Thus it must be disabled as is done with all
Anthony Towns aj@azure.humbug.org.au wrote:
Hmmm. I can't actually find any mention of this in policy. In fact,
discussion of what should be done when in prerm and postrm seems pretty
bare, period.
OK, so it's not actually in the policy.
What sequence of events is actually going to cause
Hello.
I'm about to make an update of a base Slink-system to the unstable
Potato.
Is there anything I should think of or preperations to be made before
updating?
Why I do this is because I want to become a Debian-developer, and any
hints and tips are much appreciated.
Sincerely...
yea...I just did an update today and something decided to remove /bin/sh
during the upgrade...and didn't put it back before it was needed...
so if something hoses for you just recreate it by linking it to like
bash...
Ivan
On Fri, Oct 01, 1999 at 02:24:45PM +0200, andreas pålsson wrote:
Hello.
I did an upgrade of one of my systems yesterday with little incident
(apt-get update ; apt-get dist-upgrade). I had to rerun the upgrade
part several times because the order of installation was a bit messed
up (bind).
Bob
On Fri, Oct 01, 1999 at 02:24:45PM +0200, andreas pålsson wrote:
Something I have noticed several times. If you are doing a remote upgrade
(probably a crazy idea), the telnet daemon (maybe inetd or something) becomes
unavailble for quite some time. Maybe it is between the time that netbase is
unpacked and when it is configured. There are usually problems
PROTECTED]
To: [iso-8859-1] andreas pålsson [EMAIL PROTECTED]
Cc: debian developers debian-devel@lists.debian.org
Subject: Re: slink - potato
Resent-Date: 1 Oct 1999 18:43:30 -
Resent-From: debian-devel@lists.debian.org
Resent-cc: recipient list not shown: ;
Something I have noticed
33 matches
Mail list logo
