[CC-ing tts-project@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
Attachment:
signature.asc
Description: OpenPGP digital signature