Hi Samuel, list, On 10 Jan 2026 at 23:18:24, Samuel Thibault wrote: > Hello, > > Carles Pina i Estany, le sam. 10 janv. 2026 08:06:11 +0100, a ecrit: > > 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 > > Nice! > > It'll be useful to also submit upstream.
I will send it. I'll try to add support to have it optionally before
sending it depending on systemd presence.
> They would most likely want to make the support optional on the presence
> of systemd.
note taken!
> Also, better add -lsystemd to LIBS rather than on the link line. That'll
> be needed for making the support optional anyway.
ok!
> > > > 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.
>
> It went well indeed and seems to be working fine!
super! It did work here but I didn't have time yet to test it much. Good
to know that it worked for you too.
> > > > 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).
>
> That can be nice indeed.
>
> > > 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?
>
> Sorry, I missed one word in my sentence: "Anyway that's for somebody
> else to solve."
>
> I.e. I don't think we absolutely need to care for now and can just leave
> it to further work.
Since I am not familiar about the purpose of festival server neither its
protocol, I was a bit wary of introducing a future problem. In other
words, I didn't know if festival server was an optimization but meant to
be used by a single user or built to be used by multiple users. Happy
that is for multiple users.
> > 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?
>
> If festival has some vulnerability, it can lead to information leakage,
> indeed. But again, that's already the case currently, so we are not
> making the problem worse. Actually this is making it a bit better by
> running festival as anonymous user.
yep!
> I have integrated your changes into the debian package git repository
> for now, so it'll be included in next upload.
thanks very much, and thanks for writing the changelog
> A next step would be to make festival dynamically notice the addition of
> new voices. For instance, installing festvox-italp16k after festival got
> launched, spd-say -o festival -L doesn't show it.
I am guessing that this is a festival "problem" that should detect new
voices but it is not happening.
I haven't look at festival code for finding the voices.
I am sure that ideally the festival daemon should detect and start using
the new installed voices. But, would an automatic "systemctl restart
festival" kind of thing be ok to fix the problem when installing
festvox-italp16k? Or even via a debconf question asking if festival
should be restarted? Or, are you thinking to patch festival to detect
new voices dynamically?
Thanks,
--
Carles Pina i Estany
https://carles.pina.cat | [email protected] | [email protected]
signature.asc
Description: PGP signature
