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 th
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 wil
> > > > 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!
>
> Upg
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
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 ne
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 w
> > 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?
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 t
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 docu
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 -=- http://tux.u-strasbg.fr/
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 t
> > 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 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
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, 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 fr
> 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 sam
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
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
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 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
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
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, b
Anthony Towns 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 problems? I'd have
>
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
> dae
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 2>&1; then
> ]update-inetd --disable telnet
> ] fi
>
> It might be better to bracket this with an `if [ "$1" != "upgrade" ]', or
>
> 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 post
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
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
From: John Lapeyre <[EMAIL PROTECTED]>
> To: "[iso-8859-1] andreas pålsson" <[EMAIL PROTECTED]>
> Cc: debian developers
> Subject: Re: slink -> potato
> Resent-Date: 1 Oct 1999 18:43:30 -
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipien
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
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:
> Hello
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.
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...
33 matches
Mail list logo
