Hi Cobra, On 22-04-17 21:26, Cobra wrote: > On 2017-04-22 19:51, Paul Gevers wrote: >> On 22-04-17 00:26, Cobra wrote: >>> 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). > > Might need some further testing, but imho that is speech-dispatcher's > problem, especially with the autospawn. I'd rather have > speech-dispatcher handle this correctly for all clients than make all > clients do the right thing (which they will inevitably fail to do). Good point. Agreed. >>> 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)? > > Sounds like making this package quite useless and I think it's not > necessary. Fixing init script bugs should suffice. Agree, but if fixing the bug doesn't happen in time, it will drop out of Stretch (at least if it remains with speechd-up). If we can't find the real bug (and a solution), maybe having an init script that needs to be enabled by the user is better than no speechd-up in Stretch. But see below. (And what an incredible amount of work are we putting into this package with a popcon of 9). > I was thinking of reassigning to the current speech-dispatcher version > as "breaks with pulse output when spawned by speechd-up from init > system", keeping the RC level. Please go ahead. > Does this count as "breaking unrelated > packages"? I think so, but speechd-up and speech-dispatcher aren't > completely unrelated, so I'm unsure. I don't think so. It breaks a very related package. > Without further input, I won't issue such bug control commands. Please don't hesitate further. > I'd rather open new bugs for any issues with speechd-up's init scripts > we find instead of cloning. Ok. > Yep, things are really working without pulseaudio and there aren't any > directory changes with systemd handling things. Logs are also there. > speechd-up is only breaking when speech-dispatcher is configured in a > special way, but sadly it's speech-dispatcher's default config. Ack. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature