I've looked at the bug report. I think the underlying problem is that upstream Speech-Dispatcher is moving toward a model in which the daemon is run by the user rather than system-wide.
What I don't understand is how this model is supposed to accommodate scenarios such as the following. 1. BRLTTY (with speech support) loads early in the boot process. Speech-dispatcher either has to be run as root or as a non-root system user with access to the audio device, since nobody is logged in at that point. If the user later starts an X session then we don't want a second speech-dispatcher instance to be started, as this could then compete for the audio device with the global instance - exactly what Speech-Dispatcher is designed to prevent. Killing the global instance wouldn't work, since we still need console sessions to be accessible when the X session is terminated or if the user switches to a virtual console. 2. Same as above, but with Speakup as the assistive technology. 3. Gdm log-in, possibly in combination with any of the above scenarios. Likewise for other X-based log-in tools that might become accessible at some point. 4. Administrators who log in temporarily as root from a console session instead of using su or sudo. (No, I'm not one of those except in emergencies...) I think Debian should coordinate this upstream, but in the absence of a solution to the above issues I think running it as a system-wide daemon is the only reasonable default, prefearbly as a non-root system user with suitable permissions. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
