> Seems overkill in a livecd context.

Funnily enough a livecd isn't the only context this is used :-)

The reason for the dependencies is support for various languages on various different hardware for disabled users. I've spend a relatively large amount of time on IM/IRC/email working through problems with users so our support generally works pretty well for most users.

The problem with a lot of the HW devices out there is the mix of software / hardware and languages makes various combinations of all of them works.

It's not an ideal situation but without someone who has coding skills and the available hardware (often old, esoteric with requirements of things like serial ports) to test and fix the various combinations we're out of luck.

I've not investigated if we can split some of the supported options out into subpackages.

It seems a bit self defeating to improve support for disabled users it the upper stacks of the software only to remove that support further down the stack.

(In reply to comment #1)
> The reason for the dependencies is support for various languages on various
> different hardware for disabled users. I've spend a relatively large amount of
> time on IM/IRC/email working through problems with users so our support
> generally works pretty well for most users.

That's the information I needed. Although it would be nice if a single backend worked for everything.

> That's the information I needed. Although it would be nice if a single backend
> worked for everything.

I wholeheartedly agree. The world of disabled technology seems to be fragmented and full of disagreements and in fighting. It really needs someone to choose one of the software technologies and merge any missing bits in and run with it but it's a matter of finding someone who's either interested or who will pay for it. I was sort of hoping the gnome or mozilla foundations might as part of their push. I don't remember how I managed to acquire this group of packages (likely some sort of OLPC related bit) but it's all a bit antiquated and strange.

moving to 19

*** Bug 962021 has been marked as a duplicate of this bug. ***

> I've not investigated if we can split some of the supported options out into subpackages.

The duplicate bug 962021 has a patch to that effect. Please investigate it.

Any chance we could try landing the subpackage split in F20? https://bugzilla.redhat.com/show_bug.cgi?id=962021#c2 has a patch for that.

Peter, f19 has come and gone. f20 looms, and once again we need to cut things to make the live cd fit. Can we please have the subpackage split ?!

(In reply to Matthias Clasen from comment #8)
> Peter, f19 has come and gone. f20 looms, and once again we need to cut
> things to make the live cd fit. Can we please have the subpackage split ?!

How do you propose splitting it up. I read back through years of email to remember exactly why we did it that way in the first place. The reason is language support.

See https://bugzilla.redhat.com/show_bug.cgi?id=962021#c2

Ping? Peter, can you look at the patch in https://bugzilla.redhat.com/show_bug.cgi?id=962021#c2 to see if it can be included in F21, please?

I'm looking at this, upstream is suppose to be doing a release soon so I was awaiting that landing with other fixes too

speech-dispatcher-0.8.2-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/speech-dispatcher-0.8.2-3.fc22

Package speech-dispatcher-0.8.2-3.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing speech-dispatcher-0.8.2-3.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4572/speech-dispatcher-0.8.2-3.fc22
then log in and leave karma (feedback).

I've tested the change now and it fails to speak anything in the default configuration. The problem is that the espeak module, which is the default, is now split out.

Would be great if you could move the espeak module back in the the main speech-dispatcher package.

The patch in https://bugzilla.redhat.com/show_bug.cgi?id=962021#c2 left espeak in the main package as well.

Oh, and thanks again for making the split finally happen! I'm happy to help fix up the issue with the espeak module if you want me to.

(In reply to Kalev Lember from comment #16)
> I've tested the change now and it fails to speak anything in the default
> configuration. The problem is that the espeak module, which is the default,
> is now split out.

what if you're spanish or chinese need flite or festival because it works with your language

espeak supports those languages. Try it yourself:

yum install speech-dispatcher-espeak speech-dispatcher-utils
spd-say -y es "Hola, mi nombre es Peter."

What I'd like to have is a speech-dispatcher that works out of the box without needing any additional configuration. If it works and produces some output, that enables users to change things and install additional voices or additional speech-dispatcher modules, if they so desire.

It's like having working English keyboard layout out of the box. It might not be ideal for everyone, but it works and enables users to switch to their own keyboard layout when they've gotten their systems installed.

I would be open to changing this once we get proper "Recommends:" support in yum/dnf, but right now we don't. Once we have that, it might make sense to break out the espeak module too and have speech-dispatcher "Recommends: speech-dispatcher-espeak".

One more issue I noticed is that the Obsolete versions are wrong. They should have 0.8.2, not 0.8.1.

speech-dispatcher-0.8.2-4.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/speech-dispatcher-0.8.2-4.fc22

Thanks Peter!

speech-dispatcher-0.8.2-4.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.