[Tts-project] Speech feedback related packages

[Igor B. Poretsky]

Hello Samuel,

I've updated my packages. The common fix is DEP5 compliant
debian/copyright file. Indeed, it is a good thing. I did not know.

>>>>> "Samuel" == Samuel Thibault <sthibault at debian.org> writes:

    Samuel> It is useful to have at least a mirror on salsa for the CI
    Samuel> support: there are various recipes that become very easy to
    Samuel> enable to automatically trigger lintian, piuparts,
    Samuel> reprotest, crossbuild, etc.

Ok, does matter. So, I've created an account on Salsa. My username there
is "poretsky". What should be done further?

    Samuel> debian/sd-multispeech.postinst:
    >> 
    Samuel> . /etc/default/speech-dispatcher if [ "x$RUN" != "xyes" ] ;
    Samuel> then kill $SPD
    >> 
    Samuel> This seems dangerous to kill speech dispatcher like
    Samuel> this. Some people may rely on it running to get computer
    Samuel> access. It is already a bit odd for the sd-multispeech
    Samuel> package to restart speechd (but I understand why), but
    Samuel> killing without restarting seems like a no-go to me.
    >> 
    >> Yes, I dislike it too, even though Orca, for instance, just
    >> respawn it automatically and nothing criminal happens in
    >> fact. But, as I see, the autospawn functionality can be disabled
    >> in configuration. Thus, I've specified SIGHUP signal in the kill
    >> command, that forces Speech Dispatcher to reread its
    >> configuration and, therefore, update the available modules
    >> list. Hope, it would be correct.

    Samuel> Ah, that's interesting indeed!

Moreover, as I finally figured out, it is absolutely no point to restart
Speech Dispatcher service at all, it is enough to notify all running
instances. I've fixed it as well now.

    Samuel> GPL explicitly allows modifying the source, it was meant for
    Samuel> it :)

    Samuel> It can be useful to try to contact the original authors, to
    Samuel> agree on creating a new upstream location. But legally
    Samuel> speaking, nothing prevents you from forking. When the
    Samuel> current upstream does not actually produce new releases,
    Samuel> it's better than letting things as they are.

Maybe, I should think it over.

    Samuel> But manpages are in general useful for upstream too anyway,
    Samuel> so better push them to the upstream repository.

Ok, I'll consider it, but for the moment I'd like to keep upstream
sources untouched for a while.

Best regards,
Igor.