Re: Using festival in Orca

Carles Pina i Estany <[email protected]> Sat, 10 Jan 2026 08:06:11 +0100
Newsgroups	gmane.linux.debian.devel.accessibility
Message-ID	<[email protected]>
Hi Samuel, list,

On 03 Jan 2026 at 19:06:01, Samuel Thibault wrote:
> Hello,
> 
> Carles Pina i Estany, le ven. 02 janv. 2026 08:00:10 +0100, a ecrit:
> > > > I plan to document the steps in, at least:
> > > 
> > > We'd rather integrate it into the package, so people don't have anything
> > > to do but install the speech-dispatcher-festival package.
> > 
> > I've tried to write the systemd units for socket activation for the Wiki
> > documentation and that would be re-usable to add them in the
> > speech-dispatcher-festival and I found some "blockers" (blockers for me,
> > might be possible though and happy to try again).
> > 
> > I haven't written socket activation services before but I found out:
> > I think that the application (festival in that case) should be able to
> > reuse an already opened socket? (systemctl binds 1314 and passes the
> > file descriptor to it?).
> 
> Ah, right, festival would need to be taught how to get that fd, like
> speech-dispatcher was taught.

I did it in:
https://salsa.debian.org/carlespina/festival/-/merge_requests/1

It's in draft. I want to test a bit more, but it seems to be working.
Feedback welcomed. Some notes below...

> > Then I thought that systemd could bind 1314 port, proxy to a second port
> > (1315). And systemd could spawn "festival --server" indicating 1315.
> 
> That would be a headache, better just teach festival to use
> SD_LISTEN_FDS_START:
> 
>        if (sd_listen_fds(0) >= 1) {
>                /* Daemon launched via Systemd socket activation */
>                server_socket = SD_LISTEN_FDS_START;
>        }

This is what I did.

> > This almost worked and I could make it work... but I thought that would
> > not be usable for speech-dispatcher-festival package because we want
> > each "festival --server" running using the active user, so in a
> > multi-user system that would cause problems. Is it correct that we want
> > each user to have their own "festival --server" or one as
> > "festival-server" user would be enough for the system?
> 
> Mmm, it's true that with multi-user questions rise. But if a user
> starts festival --server without socket activation the problem is
> already there, so I wouldn't bother trying to fix it. Actually, with

I implemented the socket activation. But I am still not sure of the user
details and if it's getting into a place that should not be...

What I did is socket activtation, and Festival runs as festival user
using DynamicUser=yes (my understanding is that it's a new user every
time).

> some containerization magic that could exist some day, user sessions
> could have their own 1314 port so users don't step on each other. Anyway
> that's for somebody to solve.

What would you change or double check on the Draft MR?

> 
> > For the Wiki documentation: since a user choose to enable the festival
> > --server because the user is happy with it: I thought that keeping it
> > simple is better than using socket activation. But I could change it.
> 
> Again, the end goal is to just integrate it in the festival package, so
> that users won't *even* have to set up a systemd unit, but just install
> speech-dispatcher-festival and voila.

I think that the MR would do that.

On the other hand: would it confuse or cause any problem (e.g. security
problem) in a multi-user machine to have a festival server running under
a common users for all the users in the machine? Do you foresee
something or is good enough?

Thank you!

-- 
Carles Pina i Estany
https://carles.pina.cat | [email protected] | [email protected]
signature.asc (application/pgp-signature, 833 B)