Debian Bug report logs - #541041
insserv: user changes have to be preserved

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: insserv: user changes have to be preserved

Date: Tue, 11 Aug 2009 13:20:12 +0200

Package: insserv
Version: 1.12.0-10
Severity: grave
Justification: causes non-serious data loss

If a sysadmin changes the priority of one of the init scripts manually, insserv
must not ignore this change and simply delete the link, but it does. To
reproduce simply change the priority of one script manually before enabling
insserv. This definitely loses data (namely the priority the process was
supposed to run in) and might even make the system unbootable.

Michael

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages insserv depends on:
ii  debconf [debconf-2.0]         1.5.27     Debian configuration management sy
ii  initscripts                   2.87dsf-2  scripts for initializing and shutt
ii  libc6                         2.9-24     GNU C Library: Shared libraries
ii  sysv-rc                       2.87dsf-2  System-V-like runlevel change mech
ii  sysvinit-utils                2.87dsf-2  System-V-like utilities

insserv recommends no packages.

Versions of packages insserv suggests:
pn  bootchart                     <none>     (no description available)

-- debconf information:
* insserv/enable: false

Message #8 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: 541041-submitter@bugs.debian.org

Cc: 541041@bugs.debian.org

Subject: Re: insserv: user changes have to be preserved

Date: Fri, 14 Aug 2009 12:29:01 -0500

Hi,

Just out of curiosity, why would the sys admin change it in first place? if 
the order needs to be modified then it might warrant a bug report, don't you 
think?

Regarding preserving the modified order it seems impossible to me with the 
current design of update-rc.d, but I'll leave that up to the maintainer.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #16 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Alexander Wirt <formorer@debian.org>

To: 541041@bugs.debian.org

Cc: 541041-submitter@bugs.debian.org

Subject: Re: insserv: user changes have to be preserved

Date: Fri, 14 Aug 2009 20:55:09 +0200

Hi,

> Just out of curiosity, why would the sys admin change it in first place? if 
> the order needs to be modified then it might warrant a bug report, don't you 
> think?

Here is one example directly from practise: 

amavisd-new can depend on ldap, postgresql, memcached, and several other
daemons people imagine in their config. 

Its impossible for me to reflect all possibilitys in the initscript, so its
up to the user to adjust the starting sequence so that amavisd-new is started
after his daemon. We had this case several time in a few bug reports and our
answer always was: if you need a different sequence, just change the links.

Changing links for daemon was the recommended solution for years, we really
can't change everything without a proper announcement and a question to the
user. 

Alex

Message #21 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@debian.org>

To: 541041@bugs.debian.org, 541041-quiet@bugs.debian.org

Cc: 541041-submitter@bugs.debian.org, Raphael Geissert <geissert@debian.org>

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Fri, 14 Aug 2009 20:56:20 +0200

On Fri, Aug 14, 2009 at 12:29:01PM -0500, Raphael Geissert wrote:
> Just out of curiosity, why would the sys admin change it in first place? if 

How about a local change that makes one process need ldap or a database to get
some data from while the default config doesn't do that? Or a software
monitoring some other software?

> the order needs to be modified then it might warrant a bug report, don't you 
> think?

No, why?

> Regarding preserving the modified order it seems impossible to me with the 
> current design of update-rc.d, but I'll leave that up to the maintainer.

I don't understand this sorry. It did work before the insserv mess was
introduced. Don't get me wrong, I actually like the dependency based approach
quite a lot, it just has to work, which it unfortunately didn't for me.

You might also want to see the policy that under 9.3.3.1 says:

The system administrator will have the opportunity to customize runlevels by
simply adding, moving, or removing the symbolic links in /etc/rcn.d if symbolic
links are being used [...]

I guess this alone warrants the RC status of this bug report.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Message #37 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: Michael Meskes <meskes@debian.org>, 541041@bugs.debian.org

Cc: 541041-quiet@bugs.debian.org, 541041-submitter@bugs.debian.org, Raphael Geissert <geissert@debian.org>

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Fri, 14 Aug 2009 21:51:46 +0200

Michael Meskes wrote:
> On Fri, Aug 14, 2009 at 12:29:01PM -0500, Raphael Geissert wrote:
>> Just out of curiosity, why would the sys admin change it in first place? if 
> 
> How about a local change that makes one process need ldap or a database to get
> some data from while the default config doesn't do that? Or a software
> monitoring some other software?
> 
>> the order needs to be modified then it might warrant a bug report, don't you 
>> think?
> 
> No, why?
> 
>> Regarding preserving the modified order it seems impossible to me with the 
>> current design of update-rc.d, but I'll leave that up to the maintainer.
> 
> I don't understand this sorry. It did work before the insserv mess was
> introduced. Don't get me wrong, I actually like the dependency based approach
> quite a lot, it just has to work, which it unfortunately didn't for me.
> 
> You might also want to see the policy that under 9.3.3.1 says:
> 
> The system administrator will have the opportunity to customize runlevels by
> simply adding, moving, or removing the symbolic links in /etc/rcn.d if symbolic
> links are being used [...]
> 
> I guess this alone warrants the RC status of this bug report.

Policy does not dictate what happens, but describes current practice
AFAICT. So with changing practice, it's quite normal that policy still
tells something different AFAICS.

Note that a sysadmin can still decide to change the order by making sure
that the header of the init script is correct for their environment. I'm
not sure if they would need to rerun some insserv command in that case,
but having the link changed and the header appropriate should work. Only
changing the link will of course not always work, though that's what
dependency based boot scripts are about.

I guess a debconf message explaining that the dependencies have to be
changed to change the boot order would be in order.

Cheers

Luk

Message #50 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@debian.org>

To: luk@debian.org, 541041@bugs.debian.org, 541041-quiet@bugs.debian.org, geissert@debian.org

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Sun, 16 Aug 2009 14:55:05 +0200

> Policy does not dictate what happens, but describes current practice
> AFAICT. So with changing practice, it's quite normal that policy still
> tells something different AFAICS.

It's not about policy needing an update, but about the package deleting user
changes that were doen the right way according to policy. 

After insser has been activated the admin has to make the changes by changing
the dependency headers, right. But if he made changes before installing insserv
must not override them without notice.

> I guess a debconf message explaining that the dependencies have to be
> changed to change the boot order would be in order.

I don't think this suffices. Every maintainance script that moves some startup
links to a different level was supposed to check first whether those links are
still in the default level and not touch them if they weren't. Why can't we
expect the same from insserv? 

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Message #60 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 541041@bugs.debian.org, Michael Meskes <meskes@debian.org>

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Wed, 26 Aug 2009 15:22:51 +0200

[Message part 1 (text/plain, inline)]

>> I guess a debconf message explaining that the dependencies have to be
>> changed to change the boot order would be in order.
> 
> I don't think this suffices. Every maintainance script that moves some startup
> links to a different level was supposed to check first whether those links are
> still in the default level and not touch them if they weren't. Why can't we
> expect the same from insserv? 

That is impossible. insserv can't find out [1] which set of runlevels and
priorities are the default for a given package, as we have no database for that
in Debian (contrary e.g. to Fedora/Redhat, which encode the default
runlevel/priorites in each init script header).
Only each individual package knows, which it's default runlevels/priorities are.

That's another shortcoming unfortunately of our current system.

Cheers,
Michael

[1] At least I don't know of a sane way how to do that.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #65 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: 541041@bugs.debian.org, Michael Meskes <meskes@debian.org>

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Wed, 26 Aug 2009 20:32:48 +0200

On Wed, Aug 26, 2009 at 03:22:51PM +0200, Michael Biebl wrote:
> > I don't think this suffices. Every maintainance script that moves some startup
> > links to a different level was supposed to check first whether those links are
> > still in the default level and not touch them if they weren't. Why can't we
> > expect the same from insserv? 
> 
> That is impossible. insserv can't find out [1] which set of runlevels and

Sorry, don't see the problem. If a package were to change its own old links it
will have the right levels hardcoded in the postinst. Why can't insserv do the
same?

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Message #70 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Michael Meskes <meskes@debian.org>

Cc: 541041@bugs.debian.org

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Wed, 26 Aug 2009 20:47:10 +0200

[Message part 1 (text/plain, inline)]

Michael Meskes wrote:
> On Wed, Aug 26, 2009 at 03:22:51PM +0200, Michael Biebl wrote:
>>> I don't think this suffices. Every maintainance script that moves some startup
>>> links to a different level was supposed to check first whether those links are
>>> still in the default level and not touch them if they weren't. Why can't we
>>> expect the same from insserv? 
>> That is impossible. insserv can't find out [1] which set of runlevels and
> 
> Sorry, don't see the problem. If a package were to change its own old links it
> will have the right levels hardcoded in the postinst. Why can't insserv do the

Isn't it obvious? Only each package alone knows exactly which
runlevels/priorities it's defaults are, insserv doesn't.

Do you suggest that insserv should grep for update-rc.d calls in postinst for
packages that install an init script to find out the default runlevel/priorities
of a given package?
That sounds error prone to me, as there might be multiple update-rc.d calls
(e.g. in case of upgrade scenarios) in such a postinst.

Cheers,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #75 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: Michael Meskes <meskes@debian.org>, 541041@bugs.debian.org

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Wed, 26 Aug 2009 20:58:06 +0200

On Wed, Aug 26, 2009 at 08:47:10PM +0200, Michael Biebl wrote:
> Do you suggest that insserv should grep for update-rc.d calls in postinst for
> packages that install an init script to find out the default runlevel/priorities
> of a given package?

No, I'm suggesting the maintainer could do that.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Message #80 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Michael Meskes <meskes@debian.org>

Cc: 541041@bugs.debian.org

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Wed, 26 Aug 2009 21:03:11 +0200

[Message part 1 (text/plain, inline)]

Michael Meskes wrote:
> On Wed, Aug 26, 2009 at 08:47:10PM +0200, Michael Biebl wrote:
>> Do you suggest that insserv should grep for update-rc.d calls in postinst for
>> packages that install an init script to find out the default runlevel/priorities
>> of a given package?
> 
> No, I'm suggesting the maintainer could do that.

Can you elaborate how that would work, you really lost me here.

The way insserv currently works is, that the complete system is switched in one
go, not each and every package doing the switch on it's own (which wouldn't work).

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #85 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: 541041@bugs.debian.org

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Thu, 27 Aug 2009 08:31:13 +0200

On Wed, Aug 26, 2009 at 09:03:11PM +0200, Michael Biebl wrote:
> Can you elaborate how that would work, you really lost me here.
> 
> The way insserv currently works is, that the complete system is switched in one
> go, not each and every package doing the switch on it's own (which wouldn't work).

Before doing the initial switch to dependency based booting it could check
whether all links have the default level by checking versus a list of default
numbers that can be created manually and be part of the package. Not sure where
I'm unclear to be honest. My idea was to add a file let's say call
default_runlevel.txt and then the script can go though all the links and check
whether they are listed in default_runlevel.txt or not. If one isn't the admin
has changed the priority of at least one script and thus the automatic switch
to dependency based booting should be stopped, the admin should be asked, or
whatever reaction is appropriate.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Message #90 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Michael Meskes <meskes@debian.org>

Cc: 541041@bugs.debian.org

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Thu, 27 Aug 2009 15:19:15 +0200

[Message part 1 (text/plain, inline)]

Michael Meskes schrieb:
> On Wed, Aug 26, 2009 at 09:03:11PM +0200, Michael Biebl wrote:
>> Can you elaborate how that would work, you really lost me here.
>>
>> The way insserv currently works is, that the complete system is switched in one
>> go, not each and every package doing the switch on it's own (which wouldn't work).
> 
> Before doing the initial switch to dependency based booting it could check
> whether all links have the default level by checking versus a list of default
> numbers that can be created manually and be part of the package. Not sure where

I guess you mean this list should part of the insserv package.
So, how exactly would you create such a list of default
runlevel/priorities for all packages in the archive and keep it
up-to-date? What if you are upgrading to insserv from say lenny or
testing where a package might have changed it's defaults?

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #95 received at 541041@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: Michael Meskes <meskes@debian.org>, 541041@bugs.debian.org

Subject: Re: Bug#541041: insserv: user changes have to be preserved

Date: Thu, 27 Aug 2009 16:36:52 +0200

On Thu, Aug 27, 2009 at 03:19:15PM +0200, Michael Biebl wrote:
> I guess you mean this list should part of the insserv package.

Yes.

> So, how exactly would you create such a list of default
> runlevel/priorities for all packages in the archive and keep it

Manually.

> up-to-date? What if you are upgrading to insserv from say lenny or
> testing where a package might have changed it's defaults?

To be honest I would be satisfied if it only carries a list with lenny levels
and checks against these so that admins upgrading their stable systems do not
get into trouble.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Message #104 received at 541041-close@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@debian.org>

To: 541041-close@bugs.debian.org

Subject: Bug#541041: fixed in sysvinit 2.87dsf-3

Date: Sat, 05 Sep 2009 10:53:13 +0000

Source: sysvinit
Source-Version: 2.87dsf-3

We believe that the bug you reported is fixed in the latest version of
sysvinit, which is due to be installed in the Debian FTP archive:

initscripts_2.87dsf-3_i386.deb
  to pool/main/s/sysvinit/initscripts_2.87dsf-3_i386.deb
sysv-rc_2.87dsf-3_all.deb
  to pool/main/s/sysvinit/sysv-rc_2.87dsf-3_all.deb
sysvinit-utils_2.87dsf-3_i386.deb
  to pool/main/s/sysvinit/sysvinit-utils_2.87dsf-3_i386.deb
sysvinit_2.87dsf-3.diff.gz
  to pool/main/s/sysvinit/sysvinit_2.87dsf-3.diff.gz
sysvinit_2.87dsf-3.dsc
  to pool/main/s/sysvinit/sysvinit_2.87dsf-3.dsc
sysvinit_2.87dsf-3_i386.deb
  to pool/main/s/sysvinit/sysvinit_2.87dsf-3_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 541041@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Petter Reinholdtsen <pere@debian.org> (supplier of updated sysvinit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 05 Sep 2009 11:52:51 +0200
Source: sysvinit
Binary: sysvinit sysvinit-utils sysv-rc initscripts
Architecture: source i386 all
Version: 2.87dsf-3
Distribution: unstable
Urgency: low
Maintainer: Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>
Changed-By: Petter Reinholdtsen <pere@debian.org>
Description: 
 initscripts - scripts for initializing and shutting down the system
 sysv-rc    - System-V-like runlevel change mechanism
 sysvinit   - System-V-like init utilities
 sysvinit-utils - System-V-like utilities
Closes: 519553 538934 538936 538959 539084 540546 541041 543294 544249 544555 544565
Changes: 
 sysvinit (2.87dsf-3) unstable; urgency=low
 .
   [ Petter Reinholdtsen ]
   * Drop execution of files in /etc/rc.boot from sysv-rc.  This feature
     have been obsolete since before 1999.  Remove the rc.boot(5) manual
     page from the source as well.
   * Make init.d/rc.local depend on $all to get it to start later in
     the boot sequence (Closes: #539084).
   * Rewrite message from update-rc.d to make it more obvious that both
     start and stop symlinks are taken into account (Closes: #519553).
   * Rewrite /etc/rcS.d/README and /etc/rc[2-5].d/README to explain how
     to disable a service at a given runlevel with the dependency based
     boot sequencing.  Remove the list of well known sequence numbers
     in rcS.d/ that is no longer valid with dependency based boot
     sequencing.
   * Make sysv-rc Breaks: initscripts (<< 2.86.ds1-63) to make sure
     scripts working with makefile style concurrent booting is
     installed.  Not using dependency to avoid circular dependency
     between initscripts and sysv-rc.
   * Move the code to migrate to dependency based boot sequencing
     during upgrades from the insserv package to the sysv-rc package.
     Depend on insserv (>> 1.12.0-10) for this.  Let initscripts depend
     on sysv-rc | file-rc to make sure they are installed first.
     Migration is a one-way process, enabled after a critical debconf
     question during upgrades when it is safe to do so (Closes:
     #540546, #541041).  Checks previously done by
     update-bootsystem-insserv are now only done once in sysv-rc
     postinst (Closes: #538934).  Dependency based boot sequencing is
     now the default.  This change make it possible to remove both
     sysv-rc and insserv (Closes: #538959) if other packages want to
     take over the boot sequencing resposibility.
   * Rewrite initscripts postinst to always use the update-rc.d script
     instead of the legacy updatercd() function which was used as a
     speed optimization no longer relevant when dependency based boot
     sequencing is the default.
 .
   [ Kel Modderman ]
   * Migrate from dpatch to quilt for patch management:
     - build-depend on quilt (>= 0.40)
     - provide patch and unpatch targets in debian/rules. use custom
       patch targets to allow for separate debian/patches and
       debian/startpar/patches patch series
     - keep .dpatch file extenstion to make checking changes easier
     - add debian/README.source to describe patch system we use
   * Purge debian/patches/12_doc_lastb.dpatch and
     debian/patches/68_init_quiet.dpatch, they were never applied and wrong.
   * Update patch header for all remaining patches.
   * Call dpkg-shlibdeps debian/startpar/startpar for sysvinit-utils package
     and not sysvinit, startpar moved in revision 2.86.ds1-62.
   * Remove checkdir, checkroot and buildfromsvn targets from
     debian/rules.  The latter is unused by current maintainers and the
     former can be replaced with dh_testdir and dh_testroot instead.
   * Fix reject hunk of debian/patches/70_compiler_warnings.dpatch to
     fix another compile warning.
   * Make sure update-rc.d compares command line parameters for start/stop
     runlevel configuration with the Default-Start and Default-Stop values in
     LSB info comment of script and warns if there are differences.
   * Update sysv-rc debconf templates with text which help explain
     dependency based boot to end users, and provide sound advice for
     people who encounter problems which prevent the migration.
   * Update inittab.kfreebsd-gnu: On GNU/kFreeBSD the serial devices have
     change from /dev/cuuaX to  /dev/ttydX in kernel 6.0 which is minumum
     kernel currently supported in Debian. (Closes: #544555)
   * Make sure sysv-rc/etc/init.d/rc checks insserv has reordered boot
     system by checking for /etc/init.d/.depend.* when CONCURRENCY=shell
     too. (Closes: #544565)
 .
   [ Petter Reinholdtsen ]
   * Adjust init.d/bootlogd dependencies to start before hostname,
     procps, pcmcia, hwclock, hwclockfirst, hibernate-clean and hdparm,
     to get the bootlogger started earlier in the boot (Closes: #538936).
   * Extend the update-rc.d(8) manual page to document the new behaviour.
     Do not install translated update-rc.d manual pages until they
     are updated to reflect this.
   * Use versioned conflict on chkconfig (<< 11.0-79.1-2), now that it
     dropped the service command.
   * Drop unneeded dependency rmnologin from init.d/stop-bootlogd, and
     correct $remote_fs dependency to $local_fs, as /usr/ is not aused.
   * Drop unneeded dependency on udev for init.d/bootlogs, and add ldm
     and sdm to list of display managers to start after to get the
     complete list.
   * Extend boot order migration check to reject migration if init.d
     scripts from removed but not purged packages are present.
   * Add $syslog as a dependency for init.d/skeleton, as it should
     be used in the normal case.
   * Change init.d/urandom dependency from $local_fs to $remote_fs, as
     it uses /usr/bin/find to handle locally increased pool size
     (Closes: #543294).
   * Drop initscripts conflict on insserv (<< 1.09.0-12), now that
     sysv-rc depend on insserv (>> 1.12.0-10).
   * Drop initscripts conflict on udev (<< 0.080-1), which was
     before the current oldstable was released.
   * Drop initscripts conflict on usplash (<< 0.5.8-2), which was
     before the current stable was released.
   * Remove code in init.d/killprocs to restart /sbin/update, as it is
     only useful for kernels up to linux 2.2, which is no longer
     supported (Closes: #544249).  Thanks to Marco d'Itri for the tip.
   * Update Standards-Version from 3.8.2 to 3.8.3.  No changes needed.
   * Add code in initscripts.postrm to remove rc settings for init.d
     scripts on removal to follow policy and keep lintian happy, even
     though removing initscripts will leave the system unbootable.
     Update lintian overrides to reflect this.
   * Implement status argument to init.d/bootlogs, init.d/checkroot.sh,
     init.d/hostname.sh, init.d/rmnologin and init.d/urandom.
Checksums-Sha1: 
 df5efc1940674c5925fd2e96d5590467dc1a7be6 1501 sysvinit_2.87dsf-3.dsc
 43e9ebb44e66461ecbd4bce73eda638c78a95507 153269 sysvinit_2.87dsf-3.diff.gz
 dd6ff6386c0aa5a16147711caa7e0532953d68ea 105414 sysvinit_2.87dsf-3_i386.deb
 5c193ba38ec97333ccfb320d8e5e742ba474fedd 103840 sysvinit-utils_2.87dsf-3_i386.deb
 b807a934e565980677515b61b5d0b984d4534b13 77992 initscripts_2.87dsf-3_i386.deb
 87b8c135c32d76bf500026d78961f201a84e3a77 72524 sysv-rc_2.87dsf-3_all.deb
Checksums-Sha256: 
 3704315fdf2e0aac83090531bf0fd2423850a606543dd163a2e3a5a791ced975 1501 sysvinit_2.87dsf-3.dsc
 b7a9d90151cb6b8e32b872e0055436c033686b59240f83299d8961f1be294ae7 153269 sysvinit_2.87dsf-3.diff.gz
 0189ccfb3389203901a38175c5cf4607fe96cd8a3cfd89ce86ebc7e97357ca28 105414 sysvinit_2.87dsf-3_i386.deb
 07d65b04fb464081a178cf13cdbf34e4de2b8ff7459ab39bdfaceea0f36a7866 103840 sysvinit-utils_2.87dsf-3_i386.deb
 e89c11e105ff9574552ed921ee435bb257ae1b28e87a143eb8f27055803f5280 77992 initscripts_2.87dsf-3_i386.deb
 542c06f1c08484e75e1c18166ab744f24dd3fe4e3966e1cc4391eb24d75c77d4 72524 sysv-rc_2.87dsf-3_all.deb
Files: 
 ac4e643c444b9b176fbdecf3d87a6253 1501 admin required sysvinit_2.87dsf-3.dsc
 f0a5b043ce6aa2bc3dd2354d1403d412 153269 admin required sysvinit_2.87dsf-3.diff.gz
 ae108d2261520587abfd0d8f4a4886f7 105414 admin required sysvinit_2.87dsf-3_i386.deb
 1e8e3361d949252ca712bc6eb96dc6b3 103840 admin required sysvinit-utils_2.87dsf-3_i386.deb
 b50640313871f64a996cd960ef706da9 77992 admin required initscripts_2.87dsf-3_i386.deb
 ed39f9a4be2f1fb1995cd72d56b6be06 72524 admin required sysv-rc_2.87dsf-3_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKojVB20zMSyow1ykRAuHpAKDezH7BJeXJyKONtigm4WoMdJeHlQCdG8lz
0fWhR9/+ILEWLs96H26LbNc=
=pNXj
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.