[Tts-project] Bug#859926: speechd-up: fails to install

[Paul Gevers]

[CC-ing tts-project at l.a.d.o as they are the maintainer of
speech-dispatcher; although I believe most contributers there also read
d-a11n.]

On 22-04-17 00:26, Cobra wrote:
> Looks like we're chasing a pulseaudio<->speech-dispatcher bug now. Fun.

I concluded the same based on my logs. Although there the text was
different (3 times):
[Fri Apr 21 20:04:39 2017 : 454436] speechd:  Error: Module reported
error in request from speechd (code 3xx): 300-Opening sound device
failed. Reason: Couldn't open pulse plugin.
300 UNKNOWN ERROR

> The directories are different when starting at boot:

This doesn't sound good. I think it shouldn't matter how you call an
init-script, it should behave the same. I guess this is speechd-up's
responsibility.

> At this stage, I think all these problems belong to speech-dispatcher.

Well, I am not 100% convinced. The directory for the socket apparently
comes from the environment, and I would say that that is the
responsibility of the caller (in this case speechd-up or its init-script).

> Just for the record:
> I just found out that Jessie doesn't have any issues and the only
> relevant changelog entry is "speechd-up.init: Fix startup/shutdown."
> - well, for me it looks like the other way around.

I noticed the same.

> The errcode move is a legit bug fix.

Ack.

> STARTTIME might expose some bugs but isn't the root cause of anything.
> Required-(Start|Stop) looks strange with the autospawn thing of
> speech-dispatcher. But deleting speech-dispatcher from
> Required-(Start|Stop) won't do anything - speech-dispatcher won't run
> anyway unless enabled to do so in /etc/default/speech-dispatcher.

I came to the same conclusions in my previous e-mail. Good that we agree.

> That's a dead-end, speechd-up doesn't seem to be the primary culprit.

Agree. But I wonder if for the issue at hand (installation failing due
to init script failing) we should rather give up on providing an init
script that works in all circumstances for now. It seems it may rely on
configuration of speech-dispatcher (and sound). So maybe it is best for
now to just disable the init script (in a similar way as for
speech-dispatcher)?

If not, thant I propose to clone this bug for speech-dispatcher.
Cloning, because I think that the delta in socket path is something that
speechd-up should fix. But that is probably (if it does not actually
cause this issue) not RC. But than what would be the issue for
speech-dispatcher? "speech-dispatcher doesn't work with pulse-audio when
started from init-script"? That doesn't sound like a great thing.

What do others think?

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/tts-project/attachments/20170422/067bae0c/attachment.sig>