Re: When will the orca screen reader work again?
Developing an accessible audio desktop system based on Debian myself
(http://en.wikipedia.org/wiki/Adriane_Knoppix#Adriane_Knoppix), I may be
able to answer some of your questions.
On Sun, Jun 02, 2013 at 09:01:20PM -0400, Doug Smith wrote:
> 1. Is there any idea about when the new desktop packages will make their way to testing?
> 2. Is there any new information you can give us about these packages?
> 3. Is it going to be gnome 3.6 or 3.8 that makes it to testing?
Can't answer the first three, though.
> 4. When all the packages are installed and orca is working properly again, can someone please help me to set up the talking login screen for the gnome
In my developent version of ADRIANE, orca works with the following setup:
gnome-orca 3.4.2 from Debian/unstable (same in stable/testing right now)
sbl 3.5.1 instead of brltty for braille support and console screenreader
speech-dispatcher 0.7.1 from Debian/unstable, configured as system
service. (SocketPath "/var/run/speechd.sock" in
/etc/speech-dispatcher/speechd.conf, and global environment variable
/var/run/speechd.sock read-/writable for all users.)
This setup works with lxde, various gtk2 and gtk3 programs including
LibreOffice 4, just iceweasel/firefox remains silent, I'm still
> 5. I now have orca in my startup applications for gnome because it wouldn't work on 3.4, even with the screen reader enabled in the access menu on the
> desktop main menu. Will I have to take this out and do any additional configuration?
>From my experience, manual configuration of orca and speech-dispatcher
is working much better than relying on the provided default settings.
> 6. Right now, I do not see any activity on the mailing list about which packages have been accepted into unstable or testing. Does this mean that
> there is something happening that is preventing these packages from being moved?
It can also simply mean that there is not enough manpower in the Debian
team to peristently maintain these packages. My personal experience with
Debian is, if you need to get something working quickly, which doesn't
currently do what you need, you'll have to do it by yourself and share
your results, rather than waiting for someone else to jump on it.
Putting pressure on developers and maintainers just makes things worse.
> 7. Is there anything I can do to help work on the problem that might temporarily get orca working again on this machine?
Share your configuration, once you got something working, with the
people maintaining packages, or publish your working configuration so
they can have a look at it.
> 8. When the new packages are installed on this machine, will orca just start working again, or will we have to do anything to it?
This may rather be work to be done on the side of distribution creators,
finding a working setup for their collection of software. The Debian
sample distribution apparently does not provide an orca setup that works
out-of-the-box, due to accessibility packages that just won't work
in combination with each other, in their default state.
It may be a philosophical question whether or not a Debian package
should be immediately usable after installation, or if it should only
provide a default setup that MUST be changed by the user in order to
become usable. If you are a distributor, you would probably provide a
setup that is usable, rather than an unconfigured default. I'm still not
sure about Debian's configuration philosophy, I always had to change
things in order to get a sane and usable system after instalation.
> 9. When you decide what version of the kernel to include in the next release, will it just come down to testing from unstable and be installed like
> any other package, or will we have to install it separately?
As for me, I use the (almost) vanilla kernel.org kernel and create a
package from it with make-kpkg with a special preconfiguration that I
know is working on many computers. You can find it on
> 10. I decided to use debian because of its stability, and this has proved to be true. Thanks for a good system that works even without the desktop
I fully agree with that.
> In the future, in order to avoid this happening again, how long would you recommend waiting after the next stable release before running
> any upgrades?
I wouldn't wait. After you have configured your system, upgrades of
packages (especially security upgrades) should leave your configuration
intact or migrate it to reflect a new versions syntax.
> 11. Why does mplayer crash instead of showing videos on the command line?
On the text consoles, you need framebuffer mode enabled to use mplayer
with option -vo fbdev2 . Also, you have to make sure that mplayer and
its dependency libraries match, otherwise you get warnings or segfaults
because of unmatched symbols. The control file of mplayer is not very
strict about library versions and may not automatically cause a needed
library update once you update mplayer.
> 12. Why does pulseaudio constantly roll errors on the first text console about not opening slave and a few more when it is working properly?
I recommend not using pulseaudio at all ( -> better deinstall
completely) if you are not in the situation of having to use a thin
client terminal for accessing your system over a network.