Bug 962021

Summary: pulls in both festival _and_ flite
Product: [Fedora] Fedora Reporter: Matthias Clasen <mclasen>
Component: speech-dispatcherAssignee: Peter Robinson <pbrobinson>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: jdiggs, kalevlember, pbrobinson, rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-11 15:31:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Split out festival and flite modules to separate subpackages none

Description Matthias Clasen 2013-05-11 01:20:41 UTC
flite is documented as 'an alternative to festival' - yet our speech-dispatcher package pulls in both. This hurts on the live image, which is currently oversize. Can we decide and just pull in one ?

Comment 1 Kalev Lember 2013-05-11 15:23:18 UTC
Adding Joanmarie to CC for opinions.

Comment 2 Kalev Lember 2013-05-11 15:30:24 UTC
Created attachment 746591 [details]
Split out festival and flite modules to separate subpackages

speech-dispatcher appears to default to espeak when all 3 (espeak, festival, flite) are installed. I think it would make sense to keep building speech-dispatcher in a configuration that supports all the backends -- but split up the packaging so that only one of them is installed by default.

Attaching a patch which implements this by moving the festival and flite backends to separate subpackages. The patch also makes sure to keep the festival and flite modules installed for _upgrades_, so that when someone has enabled a different backend, things should still keep working.

I've tested this with Orca on the Live media configuration (and locally) and it continues to work fine.

Comment 3 Peter Robinson 2013-05-11 15:31:25 UTC
I outlined the reasons behind this is this other ticket

*** This bug has been marked as a duplicate of bug 799140 ***

Comment 4 Peter Robinson 2013-05-11 15:32:13 UTC
> I've tested this with Orca on the Live media configuration (and locally) and
> it continues to work fine.

Tested it with various Braille serial and HW devices too?

Comment 5 Joanmarie Diggs 2013-05-11 15:52:45 UTC
(In reply to comment #4)
> > I've tested this with Orca on the Live media configuration (and locally) and
> > it continues to work fine.
> 
> Tested it with various Braille serial and HW devices too?

With respect to Orca, this change should have no impact on braille.

As a related aside, I would think this approach should lend itself nicely to providing a subpackage for the pico/svox voices. The only way I've been able to get that working in Fedora is to rebuild and install speech-dispatcher after building and installing pico/svox.

Comment 6 Peter Robinson 2013-05-11 16:03:14 UTC
> With respect to Orca, this change should have no impact on braille.

But Orca isn't the only user of speech-dispatcher and we do have Fedora users that use Fedora because our speech-dispatcher configuration works with their devices and I've spent a non insignificant amount of time ensuring that it does.

Comment 7 Joanmarie Diggs 2013-05-11 16:13:21 UTC
(In reply to comment #6)
> > With respect to Orca, this change should have no impact on braille.
> 
> But Orca isn't the only user of speech-dispatcher

I don't recall saying that it was. ;)

> and we do have Fedora
> users that use Fedora because our speech-dispatcher configuration works with
> their devices and I've spent a non insignificant amount of time ensuring
> that it does.

Then could you please provide a concrete test or set of tests (along with concrete steps) to be performed?

Comment 8 Kalev Lember 2013-05-11 16:34:31 UTC
Peter, in my (admittedly limited) understanding, speech dispatcher is about text to speech (TTS) synthesizing and doesn't have anything to do with Braille displays. Could you please be more specific what hardware configuration you are concerned about?

Having said that, I think we should try to land any F19 speech-dispatcher (and other accessibility stack changes) before F19 Beta, so that users who need TTS can test it and report back if anything is broken.

F19 Beta is the perfect opportunity for doing such tests because then interested users don't have to destructively upgrade their working systems, but can instead just boot from the live media knowing they can go back to their working installations if anything is broken. And we'll have time to fix things up before the final release.