Bug 962021 - pulls in both festival _and_ flite
pulls in both festival _and_ flite
Status: CLOSED DUPLICATE of bug 799140
Product: Fedora
Classification: Fedora
Component: speech-dispatcher (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-10 21:20 EDT by Matthias Clasen
Modified: 2013-08-13 11:28 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-11 11:31:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Split out festival and flite modules to separate subpackages (3.38 KB, text/plain)
2013-05-11 11:30 EDT, Kalev Lember
no flags Details

  None (edit)
Description Matthias Clasen 2013-05-10 21:20:41 EDT
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 11:23:18 EDT
Adding Joanmarie to CC for opinions.
Comment 2 Kalev Lember 2013-05-11 11:30:24 EDT
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 11:31:25 EDT
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 11:32:13 EDT
> 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 11:52:45 EDT
(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 12:03:14 EDT
> 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 12:13:21 EDT
(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 12:34:31 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.