Dovecot complains about missing /etc/inetd.conf is missed during install

[Markus Golser]

Binary package hint: dovecot-imapd

I installed dovecot-imapd on a fresh installation of dapper 6.06.1 server.

I have some errors:
sed: can't read /etc/inetd.conf: No such file or directory

Maybe dovecot-imapd should depend on xinetd?

[David (edeca)]

This is not actually a bug at all, it's just a warning from bash. If dovecot is installed and inetd is not, the check on /etc/inetd.conf will fail. There are two solutions:

1) Create an empty file called /etc/inetd.conf
2) Edit /etc/init.d/dovecot

The patch attached fixes this by checking that /etc/inetd.conf exists before trying to access it.

Note that dovecot works fine even with the error.

[Carlos Ribeiro (carribeiro)]

The same bug still exists on Edgy. Installed Edgy server, dovecot complainet about the missing /etc/inetd.conf. The message is not clear at all; if it's only a warning, it should clearly say so. The way it is it leaves the user unsure if dovecot will work or not.

[Carlos Ribeiro (carribeiro)]

One more note: I solved my problem installing netkit-inetd. Better safe than sorry, because I have no way to know if dovecot will ever fail because of the missing inetd.conf file.

[David (edeca)]

If you run Dovecot as a standalone daemon you do not need netkit-inetd and it will never fail without it. You can safely remove the package if you don't use it for anything else.

[Adam Wendt (adam-ipwebdev)]

Confirmed with dovecot-imapd 1.0.rc2-1ubuntu2 on Edgy
Patch appears to work

[Mathias Gug (mathiaz)]

Thanks taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - the Gutsy Gibbon.

If you need a fix for the bug in previous versions of Ubuntu, please follow the instructions for "How to request new packages" at https://help.ubuntu.com/community/UbuntuBackports#request-new-packages .

[Carlos Ribeiro (carribeiro)]

On 6/15/07, Mathias Gug <email address hidden> wrote:
> Thanks taking the time to report this bug and helping to make Ubuntu
> better. However, I am closing it because the bug has been fixed in the
> latest development version of Ubuntu - the Gutsy Gibbon.

Just a comment. In this case, can the bug be closed even if it was
reported in a LTS version (Dapper?). I thought LTS meant that bugs
*would be fixed*.

> If you need a fix for the bug in previous versions of Ubuntu, please
> follow the instructions for "How to request new packages" at
> https://help.ubuntu.com/community/UbuntuBackports#request-new-packages .
>
> ** Changed in: dovecot (Ubuntu)
> Status: Confirmed => Fix Released
>
> ** Changed in: dovecot (Debian)
> Importance: Undecided => Unknown
> Bugwatch: None => Debian Bug tracker #417299
> Status: Unconfirmed => Unknown
>
> --
> Dovecot complains about missing /etc/inetd.conf is missed during install
> https://bugs.launchpad.net/bugs/56057
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: <email address hidden>
mail: <email address hidden>

[Soren Hansen (soren)]

On Mon, Jun 18, 2007 at 12:29:49PM -0000, Carlos Ribeiro wrote:
> Just a comment. In this case, can the bug be closed even if it was
> reported in a LTS version (Dapper?). I thought LTS meant that bugs
> *would be fixed*.

It's important to remember, that in many cases, a bugfix is not merely a
1 that should have been a 0 something as simple as that. Often, to fix a
bug, you need to rewrite anything between a few lines of code to several
hundred lines of code. In doing so, it's likely that new bugs will be
introduced. For that reason, a bug needs to be very significant to
warrant an update in a released version of Ubuntu, as it may break
things for other people which would be even worse.

For that reason, we have a very strict policy when it comes to letting
*anything* new come into a released version, especially an LTS one. You
can read all about it here: https://wiki.ubuntu.com/StableReleaseUpdates

In short, bugs are generally closed when they're fixed in the current
development release. If you feel a bug is important enough to be fixed
in previously releases of Ubuntu, you can post a comment to that effect,
or you open a release task as explained in the wiki page I linked to
above.

[Carlos Ribeiro (carribeiro)]

On 6/18/07, Soren Hansen <email address hidden> wrote:
> On Mon, Jun 18, 2007 at 12:29:49PM -0000, Carlos Ribeiro wrote:
> > Just a comment. In this case, can the bug be closed even if it was
> > reported in a LTS version (Dapper?). I thought LTS meant that bugs
> > *would be fixed*.
>
> It's important to remember, that in many cases, a bugfix is not merely a
> 1 that should have been a 0 something as simple as that. Often, to fix a
> bug, you need to rewrite anything between a few lines of code to several
> hundred lines of code. In doing so, it's likely that new bugs will be
> introduced. For that reason, a bug needs to be very significant to
> warrant an update in a released version of Ubuntu, as it may break
> things for other people which would be even worse.
>
> For that reason, we have a very strict policy when it comes to letting
> *anything* new come into a released version, especially an LTS one. You
> can read all about it here: https://wiki.ubuntu.com/StableReleaseUpdates
>
> In short, bugs are generally closed when they're fixed in the current
> development release. If you feel a bug is important enough to be fixed
> in previously releases of Ubuntu, you can post a comment to that effect,
> or you open a release task as explained in the wiki page I linked to
> above.

Ok, thanks for the clarification. As I said, it was just a comment on
my part, so please don't take me wrong.

So forgive me as I'm not a Launchpad Guru, I'm only a casual user...
Is it possible to mark bugs as closed for a release but still opened
or with a different status (ex: "Wont Fix" or "Workaround exists") for
previous releases? That would be useful not only for this particular
case but for any similar issue that affect a LTS release. Another idea
would be to document issues like this in the "Release Notes" for
Dapper - but I'm not sure if it would be worth the effort.

Thanks for the prompt answer and best regards.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: <email address hidden>
mail: <email address hidden>