Bug 962021
Summary: | pulls in both festival _and_ flite | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matthias Clasen <mclasen> | ||||
Component: | speech-dispatcher | Assignee: | Peter Robinson <pbrobinson> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 19 | CC: | 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
Matthias Clasen
2013-05-11 01:20:41 UTC
Adding Joanmarie to CC for opinions. 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.
I outlined the reasons behind this is this other ticket *** This bug has been marked as a duplicate of bug 799140 ***
> 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?
(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. > 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.
(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? 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. |