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

Bug #56057 reported by Markus Golser
8
Affects Status Importance Assigned to Milestone
dovecot (Debian)
Fix Released
Unknown
dovecot (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

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?

Revision history for this message
David (edeca) wrote :

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.

Revision history for this message
Carlos Ribeiro (carribeiro) wrote :

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.

Revision history for this message
Carlos Ribeiro (carribeiro) wrote :

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.

Revision history for this message
David (edeca) wrote :

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.

Revision history for this message
Adam Wendt (adam-ipwebdev) wrote :

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

Changed in dovecot:
status: Unconfirmed → Confirmed
Revision history for this message
Mathias Gug (mathiaz) 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.

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:
status: Confirmed → Fix Released
status: Unconfirmed → Unknown
Changed in dovecot:
status: Unknown → Fix Released
Revision history for this message
Carlos Ribeiro (carribeiro) wrote : Re: [Bug 56057] Re: Dovecot complains about missing /etc/inetd.conf is missed during install

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>

Revision history for this message
Soren Hansen (soren) 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.

Revision history for this message
Carlos Ribeiro (carribeiro) wrote :

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>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.