Dependency based boot sequencing reaches 2/3 threshold (Was: Please all dependency info into your init.d script)

[Petter Reinholdtsen]

When measuring the amount of packages in Debian/sid with dependency
information for their init.d scripts today, I was very happy to
discover that more than 2/3 of the packages in Sid now have dependency
information included.  Only one base package is missing it
(libdevmapper1.02.1), and only three more packages included in the
desktop profile (hotkey-setup, anacron and resolvconf).

I've used dependency based init.d sequencing in my sid chroot for more
than half a year now, and it has worked just fine.  To test it
yourself, see the talk I gave at at Debconf, see
https://penta.debconf.org/~joerg/events/21.en.html> for a recipe.

The status for the dependency based boot sequencing is updated on the
wiki page
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot>.

There is a small bug in the insserv I use to reorder the boot sequence
based on the dependency info.  It does not properly order the
shutdown/halt sequence.  I welcome patches to solve it. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Francesco P. Lovergine]

On Wed, Oct 24, 2007 at 11:53:54AM +0200, Petter Reinholdtsen wrote:
> 
> > I've created
> > http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> to
> > track the progress of this work.  See also
> > http://wiki.debian.org/LSBInitScripts> for clues on how to write
> > such header.
> 
> Please have a look at the URL above and fix your packages. :)
> 

Of course, there are also packages not listed here with an init script
which needs fixing. At least about me, there are for sure autodir and
aolserver4 missing, so I guess the current situation is worst than
what it seems :) I guess mass bug filing should be tempted in order
to change the current status and warns as many maintainer as possible.

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Petter Reinholdtsen]

Here is a small status update on the dependency based init.d script
ordering effort.

[Petter Reinholdtsen]
> As you might be aware, there are several bugs in the Debian boot
> sequence.  The bugs affect some combinations of packages, and are some
> times hard to solve.  To solve them once and for all, I want us to
> switch to a dependency based sequencing of the symlinks in
> /etc/rc*.d/.  I gave a talk about this at Debconf, see
> https://penta.debconf.org/~joerg/events/21.en.html> for the
> slides and more info.

This still holds.

> For this to work properly, all init.d scripts need to provide
> dependency information.  There is a standard for specifying such
> dependency information in the LSB, and already 56% of the Debian
> packages in unstable include the header with dependency information.
> This message is for the rest of you.
>
> I've created
> http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> to
> track the progress of this work.  See also
> http://wiki.debian.org/LSBInitScripts> for clues on how to write
> such header.

Please have a look at the URL above and fix your packages. :)

The amount of packages missing such headers have gone from 44% this
summer to 38% at the moment.  Most of the packages in a desktop
install is already converted, but a few vital ones are still missing.

I've used insserv in my sid chroot as a replacement for update-rc.d
since this summer, and it seem to work fairly well.  There are enough
override files to get a correct boot sequence.

There is a small bug in insserv when it comes to the shutdown
sequence, and I have not been able to figure it out yet.  This leads
to a slightly wrong halt and reboot sequence, even if the init.d
script headers are correct.  I hope to find a solution to this issue
soon.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Fri, Jul 13, 2007 at 07:18:17AM +0200, Adrian von Bidder wrote:

>> Hmmm.  With slapd, for example, it's certainly possible where one
>> scenario (slapd uses SQL database) directly contradicts another
>> scenario (startup of SQL database uses auth info which is provided by
>> slapd).

>> Not sure how a packager should deal with this.  (slapd being used only
>> as an example.  Other scenarios for other services are certainly
>> possible.)

> Well, the OpenLDAP maintainers are likely to deal with this by declaring
> that a SQL server that needs to read auth info out of LDAP for startup
> is not supported, and the admin is on their own for making this work.

> All Debian system accounts should be stored in the nss_files backend,
> where adduser will put them by default.  If your system accounts are in
> LDAP, you're making your system deliberately fragile, and I see no
> reason for Debian to make that easier to do.

Note that we've had to deal with this problem previously in the OpenLDAP
package.  I think the most recent example was a DNS server that required
the directory be available, when the directory wanted to look things up in
DNS.  Most of these sorts of problems are best resolved by making one or
the other service more robust in the face of such resources not being
available at startup.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Steve Langasek]

On Fri, Jul 13, 2007 at 07:18:17AM +0200, Adrian von Bidder wrote:
> On Tuesday 10 July 2007 20.04:38 Russ Allbery wrote:
> > Toni Mueller <[EMAIL PROTECTED]> writes:

> > > Slapd may require an
> > > external SQL server if a suitable backend is defined, and I guess that
> > > a whole slew of other applications have similar problems.

> > You should require everything you might use directly using the
> > Should-Start stanza, which says that you should start after those
> > services if anything provides them but that not having them available
> > isn't an error.

> Hmmm.  With slapd, for example, it's certainly possible where one scenario 
> (slapd uses SQL database) directly contradicts another scenario (startup of 
> SQL database uses auth info which is provided by slapd).

> Not sure how a packager should deal with this.  (slapd being used only as an 
> example.  Other scenarios for other services are certainly possible.)

Well, the OpenLDAP maintainers are likely to deal with this by declaring
that a SQL server that needs to read auth info out of LDAP for startup is
not supported, and the admin is on their own for making this work.

All Debian system accounts should be stored in the nss_files backend, where
adduser will put them by default.  If your system accounts are in LDAP,
you're making your system deliberately fragile, and I see no reason for
Debian to make that easier to do.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Adrian von Bidder]

On Tuesday 10 July 2007 20.04:38 Russ Allbery wrote:
> Toni Mueller <[EMAIL PROTECTED]> writes:

> > Slapd may require an
> > external SQL server if a suitable backend is defined, and I guess that
> > a whole slew of other applications have similar problems.
>
> You should require everything you might use directly using the
> Should-Start stanza, which says that you should start after those
> services if anything provides them but that not having them available
> isn't an error.

Hmmm.  With slapd, for example, it's certainly possible where one scenario 
(slapd uses SQL database) directly contradicts another scenario (startup of 
SQL database uses auth info which is provided by slapd).

Not sure how a packager should deal with this.  (slapd being used only as an 
example.  Other scenarios for other services are certainly possible.)

cheers
-- vbi

-- 
featured link: http://fortytwo.ch/gpg/intro


signature.asc
Description: This is a digitally signed message part.

Re: Please all dependency info into your init.d script

[Petter Reinholdtsen]

[Vincent Danjean]
> What about circular dependencies that must be broken differently
> depending on the admin configuration ?

[Henrique de Moraes Holschuh]
> You have your answer right there: let the admin fix it.

Exactly.  And the insserv system provides a system where overrides are
read from /etc/insserv/overrides for such use (or the admin can just
edit the scripts directly).  Of course, circular dependencies are a
nasty problem already with the current ordering mechanism, and a
source of several of the bugs in the current boot sequencing.

So please add dependency information into all init.d scripts missing
them today, to make it possible to detect the current circular
dependencies that need to be solved before Lenny.  Without dependency
information, it is a lot harder to detect these problems.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Henrique de Moraes Holschuh]

On Tue, 10 Jul 2007, Vincent Danjean wrote:
> What about circular dependencies that must be broken differently
> depending on the admin configuration ?

You have your answer right there: let the admin fix it.

> For example, looking at openvpn and nfs :
> * On some machines, openvpn must depend (perhaps not directly) on nfs
>   if /usr is nfs-mounted
> * On other machines, nfs must depend on openvpn because openvpn is
>   needed to reach the nfs server

We support the most common setup, then (local or not-over-openvpn-nfs /usr).

> This is the first example that come to my mind. I am sure we can find
> lots of other similar examples.
> How should this be solved with static headers dependencies ?

It *cannot*.  Heck, sometimes it cannot be solved even by dynamic (as in
calculated at runtime) dependencies.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Vincent Danjean]

Petter Reinholdtsen wrote:

The current proposal is to document dependencies in the init.d scripts
themselves (or override files while we wait for the init.d scripts to
be updated), and then replace the update-rc.d program with a program
that take these dependencies into account when creating the symlinks
in /etc/rc*.d/.  This will fix a few long-standing bugs in the current
boot and shutdown sequence.


What about circular dependencies that must be broken differently
depending on the admin configuration ?

For example, looking at openvpn and nfs :
* On some machines, openvpn must depend (perhaps not directly) on nfs
  if /usr is nfs-mounted
* On other machines, nfs must depend on openvpn because openvpn is
  needed to reach the nfs server

This is the first example that come to my mind. I am sure we can find
lots of other similar examples.
How should this be solved with static headers dependencies ?

  Best regards,
Vincent


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Petter Reinholdtsen]

[Toni Mueller]
> Packages may or may not require services, depending on actual
> runtime configuration. Eg. roundup can use one or more out of a
> number of database mechanisms, some of which require external SQL
> servers, and at least one that doesn't.

Correct.

> Request-Tracker may be run at least with MySQL or PostgreSQL, so
> require which?

It should list both, as optional requirements.  In other words, it
should include 'should-start: mysql postgresql' (or whatever those
init.d scripts are called).

> What if the configuration specifies one while a "virtual service"
> $sqldatabase (purely fictional) might provide only the other? Should
> we require both? Slapd may require an external SQL server if a
> suitable backend is defined, and I guess that a whole slew of other
> applications have similar problems.

This is not as hard as you make it sound.  The init.d scripts that
should start before a given init.d script if present should be listed
as should-start (optional), and those that are always present should
be listed as required-start.

> To me, the one big question is why you want to stick with the SysV
> init script system instead of eg. switching to runit (my personal
> favourite, w/o having looked far, yet - but it's hard to get worse
> than SysV init, so...).

Well, while replacing the boot system might be an interesting goal, I
believe it will be a very long process to get the Debian project to
agree on such change, and even longer to change all packages to use
it.  This is the reason I have decided to focus my effort on fixing
the bugs in the current boot system using mechanism that do not depend
on changing a lot of packages, and which will do the least amount of
changes required to fix the problem.

The current proposal is to document dependencies in the init.d scripts
themselves (or override files while we wait for the init.d scripts to
be updated), and then replace the update-rc.d program with a program
that take these dependencies into account when creating the symlinks
in /etc/rc*.d/.  This will fix a few long-standing bugs in the current
boot and shutdown sequence.

> IOW, I'm very doubtful that adding this new complexity really solves
> the problem instead of (maybe) making it even worse - worse, because
> the limited usefulness is now offset by increased changes for packaging
> errors and maintenance burden.

Well, some of us have spent quite a lot of time thinking about the
boot system, and personally I have concluded that fixing the current
boot sequence is fixable in the lenny time frame, while replacing it
with a completely new approach is not.  I believe rewriting all 843
packages with init.d scripts to use another system is not possible at
the moment, so I focus on the fix that can have most positive effect
in the short to medium time frame.

It is possible to have the sysv boot sequence ordered using dependency
information in that time frame, as it can be done by only updating a
single package while we wait for the package maintainers to add the
most updated information to their package.  Providing this information
outside the package it not going to be maintainable, as such
information will always fall out of sync with the package itself, so
it is best to keep it as part of the individual init.d scripts.

At the moment, 473 of 843 (56%) packages already provide the headers
with dependency information, and I expect us to be able to get most of
the rest to include them for Lenny.  For the remaining packages, we
can provide override headers outside the package as an interim
solution.

> I suggest that we take a step back and first examine the field and
> determine a solution instead of rushing to action with SysV init
> (for no perceivable gain, imho), and if I can wish something for
> Lenny right now, dropping SysV in favour of a better alternative is
> high on my list.

If you want to work on the boot system, I absolutely welcome your time
and interest.  The initscripts-ng alioth project and assosiated
mailing list is the current gathering point.  The various boot systems
have been discussed on the list.  You might find the discussion there
interesting.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Russ Allbery]

Toni Mueller <[EMAIL PROTECTED]> writes:

> Packages may or may not require services, depending on actual runtime
> configuration. Eg. roundup can use one or more out of a number of
> database mechanisms, some of which require external SQL servers, and at
> least one that doesn't. Request-Tracker may be run at least with MySQL
> or PostgreSQL, so require which? What if the configuration specifies one
> while a "virtual service" $sqldatabase (purely fictional) might provide
> only the other? Should we require both? Slapd may require an external
> SQL server if a suitable backend is defined, and I guess that a whole
> slew of other applications have similar problems.

You should require everything you might use directly using the
Should-Start stanza, which says that you should start after those services
if anything provides them but that not having them available isn't an
error.

> To me, the one big question is why you want to stick with the SysV init
> script system instead of eg. switching to runit (my personal favourite,
> w/o having looked far, yet - but it's hard to get worse than SysV init,
> so...).

Because modifying a thousand packages in Debian to provide two different
init systems (or more -- everyone has their own favorite) is a really good
definition of "not fun."  We already have a huge infrastructural
investment in System V init scripts.

> IOW, I'm very doubtful that adding this new complexity really solves the
> problem instead of (maybe) making it even worse - worse, because the
> limited usefulness is now offset by increased changes for packaging
> errors and maintenance burden.

It's better than trying to maintain start sequence numbers, honestly.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Toni Mueller]

Hi,

On Fri, 06.07.2007 at 22:43:31 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
wrote:
> As you might be aware, there are several bugs in the Debian boot
> sequence.  The bugs affect some combinations of packages, and are some
> times hard to solve.  To solve them once and for all, I want us to
> switch to a dependency based sequencing of the symlinks in
> /etc/rc*.d/.  I gave a talk about this at Debconf, see
> https://penta.debconf.org/~joerg/events/21.en.html> for the
> slides and more info.

Packages may or may not require services, depending on actual runtime
configuration. Eg. roundup can use one or more out of a number of
database mechanisms, some of which require external SQL servers, and at
least one that doesn't. Request-Tracker may be run at least with MySQL
or PostgreSQL, so require which? What if the configuration specifies
one while a "virtual service" $sqldatabase (purely fictional) might
provide only the other? Should we require both? Slapd may require an
external SQL server if a suitable backend is defined, and I guess that
a whole slew of other applications have similar problems.

To me, the one big question is why you want to stick with the SysV init
script system instead of eg. switching to runit (my personal favourite,
w/o having looked far, yet - but it's hard to get worse than SysV
init, so...). 

IOW, I'm very doubtful that adding this new complexity really solves
the problem instead of (maybe) making it even worse - worse, because
the limited usefulness is now offset by increased changes for packaging
errors and maintenance burden.

I suggest that we take a step back and first examine the field and
determine a solution instead of rushing to action with SysV init (for
no perceivable gain, imho), and if I can wish something for Lenny right
now, dropping SysV in favour of a better alternative is high on my
list.

> http://wiki.debian.org/LSBInitScripts> for clues on how to write
> such header.

I've read that as well, but could not find an answer to my questions
there.

Thank you for listening!


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Petter Reinholdtsen]

[Neil McGovern]
> Blootbot requires a mysql database to be up and running, or it will
> fail. However, this database doesn't need to be on the local
> host. How's best to handle this situation in the init script
> dependencies?

I suggest adding the mysql init.d script in the should-start header,
to make sure the blootbot script is started after mysql, if mysql is
installed on the same machine.  I also suggest adding $remote_fs in
the required-start header to make sure the network is up and all file
systems are mounted before the blootbot script runs.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please all dependency info into your init.d script

[Neil McGovern]

On Fri, Jul 06, 2007 at 10:43:31PM +0200, Petter Reinholdtsen wrote:
> For this to work properly, all init.d scripts need to provide
> dependency information.
[snip]
> Neil McGovern <[EMAIL PROTECTED]>
>blootbot

Blootbot requires a mysql database to be up and running, or it will
fail. However, this database doesn't need to be on the local host. How's
best to handle this situation in the init script dependencies?

Neil
ps: please CC: or I may not see your mail for quite some time.
-- 
 So we can expect stockholm to be elected in 2009?
 isnt the world own3d by ubuntu then?



signature.asc
Description: Digital signature

Please all dependency info into your init.d script

[Petter Reinholdtsen]

As you might be aware, there are several bugs in the Debian boot
sequence.  The bugs affect some combinations of packages, and are some
times hard to solve.  To solve them once and for all, I want us to
switch to a dependency based sequencing of the symlinks in
/etc/rc*.d/.  I gave a talk about this at Debconf, see
https://penta.debconf.org/~joerg/events/21.en.html> for the
slides and more info.

For this to work properly, all init.d scripts need to provide
dependency information.  There is a standard for specifying such
dependency information in the LSB, and already 56% of the Debian
packages in unstable include the header with dependency information.
This message is for the rest of you.

I've created
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> to
track the progress of this work.  See also
http://wiki.debian.org/LSBInitScripts> for clues on how to write
such header.

The following packages are according to lintian missing the LSB
headers.  Please add dependency information to these packages soon.
Without it, it is very hard to verify the correctness of the debian
boot sequence, and equally hard to switch to a dependency based boot
sequencing.  Some proposed headers are available in the insserv
package, directory /usr/share/insserv/override/, so if you are lucky
you can pick it from there.

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   realtime-lsm

Laszlo Boszormenyi (GCS) <[EMAIL PROTECTED]>
   metalog

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   courier
   courier-authlib
   interchange
   pure-ftpd
   sympa

Cyril Lacoux (Yack) <[EMAIL PROTECTED]>
   digitools

Marco Presi (Zufus) <[EMAIL PROTECTED]>
   linesrv

Peter De Schrijver (p2) <[EMAIL PROTECTED]>
   linux-atm

Stefan Alfredsson <[EMAIL PROTECTED]>
   monit

Pierre Ancelot <[EMAIL PROTECTED]>
   hwtools

Osamu Aoki <[EMAIL PROTECTED]>
   tpconfig

Ben Armstrong <[EMAIL PROTECTED]>
   xpilot-ng

Don Armstrong <[EMAIL PROTECTED]>
   spamass-milter

SZALAY Attila <[EMAIL PROTECTED]>
   zorp

Julien BLACHE <[EMAIL PROTECTED]>
   smcroute

Joost van Baal <[EMAIL PROTECTED]>
   uruk

Alan Bain <[EMAIL PROTECTED]>
   rbootd

Andreas Barth <[EMAIL PROTECTED]>
   dhcp
   mgetty

Daniel Baumann <[EMAIL PROTECTED]>
   ipac-ng
   ipmasq
   nfs-user-server

Edelhard Becker <[EMAIL PROTECTED]>
   atop

Hilko Bengen <[EMAIL PROTECTED]>
   ulog-acctd

Grzegorz Bizon <[EMAIL PROTECTED]>
   specter

Bastian Blank <[EMAIL PROTECTED]>
   omniorb4
   redhat-cluster

Blars Blarson <[EMAIL PROTECTED]>
   cnews

Eduard Bloch <[EMAIL PROTECTED]>
   apt-cacher
   scsi-idle

Ed Boraas <[EMAIL PROTECTED]>
   aime
   tinyproxy

W. Borgert <[EMAIL PROTECTED]>
   blinkd

Cyril Bouthors <[EMAIL PROTECTED]>
   bld
   drbdlinks

Chris Boyle <[EMAIL PROTECTED]>
   reaim

Joachim Breitner <[EMAIL PROTECTED]>
   infon

Adrian Bridgett <[EMAIL PROTECTED]>
   dante

Eric Van Buggenhaut <[EMAIL PROTECTED]>
   udhcp

Chris Butler <[EMAIL PROTECTED]>
   wu-ftpd

Bruno Barrera C. <[EMAIL PROTECTED]>
   portsentry

Patrick Caulfield <[EMAIL PROTECTED]>
   mopd

Emmanuel le Chevoir <[EMAIL PROTECTED]>
   frox

Dennis L. Clark <[EMAIL PROTECTED]>
   bnetd

Isaac Clerencia <[EMAIL PROTECTED]>
   wesnoth

Jesus Climent <[EMAIL PROTECTED]>
   distmp3

Russell Coker <[EMAIL PROTECTED]>
   memlockd

Jamin W. Collins <[EMAIL PROTECTED]>
   jabber

Carlo Contavalli <[EMAIL PROTECTED]>
   wipl

Leo Costela <[EMAIL PROTECTED]>
   knockd

Paul Cupis <[EMAIL PROTECTED]>
   guarddog
   guidedog

Artur R. Czechowski <[EMAIL PROTECTED]>
   rrdcollect

Julien Danjou <[EMAIL PROTECTED]>
   ledstats
   sysrqd
   tetrinetx
   tleds

Debian ALSA Maintainers <[EMAIL PROTECTED]>
   alsa-tools

Debian CUPS Maintainers <[EMAIL PROTECTED]>
   cupsys

Debian GNUstep maintainers <[EMAIL PROTECTED]>
   gnustep-base

Debian Hamradio Maintainers <[EMAIL PROTECTED]>
   ssbd

Debian Icecast team <[EMAIL PROTECTED]>
   icecast2

Debian Java Maintainers <[EMAIL PROTECTED]>
   tomcat5

Debian LVM Team <[EMAIL PROTECTED]>
   devmapper
   lvm-common
   lvm2
   multipath-tools

Debian Nagios Maintainer Group <[EMAIL PROTECTED]>
   nsca

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   kdenetwork

Debian VoIP Team <[EMAIL PROTECTED]>
   bayonne
   rtpproxy
   ser
   siproxd
   stun
   yate

Debian/Ubuntu Zope Team <[EMAIL PROTECTED]>
   schooltool

Eric Delaunay <[EMAIL PROTECTED]>
   scsitools

Cédric Delfosse <[EMAIL PROTECTED]>
   darkstat

Jean-Francois Dive <[EMAIL PROTECTED]>
   l2tpd

Bernd Eckenfels <[EMAIL PROTECTED]>
   net-acct
   transproxy

Nick Estes <[EMAIL PROTECTED]>
   upsd

Martín Ferrari <[EMAIL PROTECTED]>
   vtun

Agney Lopes Roth Ferraz <[EMAIL PROTECTED]>
   fnfx

Duncan Findlay <[EMAIL PROTECTED]>
   spamassassin

Decklin Foster <[EMAIL PROTECTED]>
   lastfmsubmitd
   mpd

Turbo Fredriksson <[EMAIL PROTECTED]>
   roxen4

Jochen Friedrich <[EMAIL PROTECTED]>
   isakmpd
   snmptrapfmt

Peter S Galbraith <[EMAIL PROTECTED]>
   xtide

Radovan Garabik <[EMAIL PROTECTED]>
   serpento