[Tts-project] Speech feedback related packages

[Samuel Thibault]

Hello,

Igor B. Poretsky, le mer. 22 nov. 2023 19:24:33 +0300, a ecrit:
> >>>>> "Samuel" == Samuel Thibault <sthibault at debian.org> writes:
> 
>     Samuel> Hello, Here rather keeping the pkg-a11y-devel list in Cc,
>     Samuel> where Debian maintainers are, and not users :)
> 
> So, should I announce there as well now?

When the packages will be uploaded to the archive, it'll be nice to
announce on debian-accessibility, but for now for the technical
discussions, better not bother the users.

>     >> So, these are:
> 
>     Samuel> These don't seem to have a git repository? It would make it
>     Samuel> way easier to maintain that you put them on salsa, you can
>     Samuel> create yourself an account and I can give you access to the
>     Samuel> tts-team group.
> 
> Actually, all my projects live on Github
> (https://github.com/poretsky). Does it matter to mirror these ones on
> Salsa nevertheless?

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

>     Samuel> You'll want a sid branch that contains the current
>     Samuel> unstable/testing version.
> 
> At the moment I use master branch for Debian package and upstream branch
> for upstream source. It is the default in git-buildpackage. Should I
> change repository layout?

Just like you prefer :)

>     Samuel> debian/sd-multispeech.postinst:
> 
>     Samuel>         . /etc/default/speech-dispatcher if [ "x$RUN" !=
>     Samuel> "xyes" ] ; 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.

Ah, that's interesting indeed!

>     Samuel> Actually, is there still an upstream for this? If not, you
>     Samuel> probably want to re-create one, and apply your patches in
>     Samuel> it. We don't want to make debian the only owner of these
>     Samuel> patches, and rather see this go out in the wild so people
>     Samuel> can include it into other distributions and contribute
>     Samuel> patches as well.
> 
> Upstream source exists, but it is not mine. I found it at
> http://tcts.fpms.ac.be/synthesis/mbrola/tts/English/fs.a10m.tar.gz some
> time ago. I don't know whether it can be downloaded there now or found
> at some other place. I did not succeed to find an alternative
> location. The code is distributed under GPL license, so, I think that I
> use it legally. I treat it as an original upstream source, so, it is
> placed in the upstream branch of my repository. Of course, I can commit
> all my patches to this branch. Should I do it?

No, what I mean is create an upstream repository, i.e. a git repository
(without the debian-specific pieces) that other distributions can fetch
the newest upstream sources from.

> The only thing that keeps me from doing it is that I cannot get the
> original author agreement.

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

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

>     Samuel> Also, in general you'd want to push the manual pages to
>     Samuel> upstream rather than keeping them in debian/
> 
> There were no manual pages in the original freespeech source. I've made
> them especially for the Debian package consistency. And for ru-tts
> package, I think that manual pages are not essential for its upstream
> sources since it is sufficiently documented by README files.

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

Samuel