So far, none of the people reporting this bug have provided information that can be used to track it down. Most users are quoting the failure to set up openbsd-inetd -- that's not news, what we need is output from the *unpack* stage of the upgrade showing why the attempt to *stop* the previous inetd failed.
Others are quoting dpkg logs showing that they've only upgraded to version -4, when this bug is being reported against version -5. That doesn't clarify anything; we need to see that the bug is happening with the current version of the package, not obsolete versions that have been removed from the archive. Others are providing aptitude logs, which tell nothing about what went wrong in dpkg. A good report to work with on this bug is going to be: - what version of openbsd-inetd you were upgrading from (this information is avaliable from dpkg.log) - logs showing what happened when unpacking the new version of openbsd-inetd - confirmation that you are installing the *current* version of openbsd-inetd -- that's version -5, not version -4 - ps output showing the inetd processes running after the point at which the new version of the package has failed to configure There are lots of theories about what's happening here, but without the above information as a starting point, they're effectively impossible to investigate. -- 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]
