Re: Speech-Dispatcher Won't Install
Chime, There were a few things wrong with your installation - at least from our last conversation. You had both your voxin IBM-TTS voice installed and your new Voxin Embedded voice installed; You cannot have both installed when you are using console speech, you can have both if you just use orca inside MATE or other graphical user interface. I advised you to completely uninstall voxin from your system using the voxin install with the switch -u to uninstall. I don't know any way to just uninstall one voice and not the other and it's easier just to uninstall everything. You will still have espeakng to speak in the console. You told me in this email that you uninstalled voxinup - which is good. Voxinup has been discontinued. It has been replaced by speechd-up. Here are the errors you sent me - I apologize I did not see your email until after I read your email to Debian-Accessibility. >From reading your email it seems you did NOT uninstall voxin as I suggested. Uninstall voxin using the voxin installer you were provided with with the "-u" switch, it will remove all voices from your system, then install just the voxin embedded voice you want in your console. The voxin installer will install and configure the system for you, with one exception. Since you are using console, you will not have your voxin voice at the log in screen, you will have espeakup. The README file within the voxin archive tells you how to configure spd-conf as user, but you MUST also configure it system wide by using your root account to have your voxin embedded voice at login. You also must reboot after doing this, and when you reboot you should have your installed voice. You can test the voice using: spd-say "Hello" and voxin-say "Hello" | aplay Your email to me appears below my signature, but what I see is that you didn't do as I asked you to: Uninstall voxin and the reinstall it using ONLY the voice you wish to hear. I believe you have Samantha and another voice as well as the original IBM TTS in English. Also note that although the IBM TTS voice is supported with emacspeak, the emacspeak engine for Voxin Embedded has not been designed yet, there were some one the emacspeak list that were interested in doing that, but it always takes time. I'm looking forward to the day when Voxin embedded voices are available for emacspeak, but that day is in the future. The only voxin voice supported now is the IBM TTS voice, and if you install that voice, you will have difficulties in getting your desired voice in console. It can be done however, but it must be done by manually reconfiguring the configuration files of speech dispatcher to do so, and that is more difficult for me than is worth while. With ORCA, it is just a matter of selecting the desired voice, with console, the configuration files must be edited individually if more than one voice is installed. Uninstall voxin completely, then install the voice you wish to use - only one voice - and voxin will install speechd-up for you. As explained above, as it's not yet documented in the README file within the voxin archive files, to have voxin embedded voice at log in when using console to log in, you must also use spd-conf under root to configure system wide. Use the same instructions in the README file for configurating spd-conf as user but do so using root and using system wide, the answers will be the same as given in the README file. Best wishes, David Chime wrote to me off list: Last evening I did uninstall voxin up, but as you will see I had errors installing speechd-up. Since I am not running a graphical desktop, I don't need ORCA, but will look at your other suggestions, especially after we come home on Wednesday. Removing voxinup (1:2.3.3-1) ... Setting up speechd-up (0.5~20110719-11) ... Job for speechd-up.service failed because the control process exited with error code. See "systemctl status speechd-up.service" and "journalctl -xeu speechd-up.service" for details. invoke-rc.d: initscript speechd-up, action "restart" failed. x speechd-up.service - LSB: Interface between speakup and speech-dispatcher Loaded: loaded (/etc/init.d/speechd-up; generated) Active: failed (Result: exit-code) since Sat 2022-03-05 20:48:10 PST; 33ms ago Docs: man:systemd-sysv-generator(8) Process: 456446 ExecStart=/etc/init.d/speechd-up start (code=exited, status=1/FAILURE) CPU: 29ms Mar 05 20:48:08 chime speechd-up[456446]: Starting Interface between speakup and speech-dispatcher : speechd-up Mar 05 20:48:08 chime speechd-up[456451]: [Sat Mar 5 20:48:08 2022] speechd: Configuration has been read from "/etc/speechd-up.conf" Mar 05 20:48:08 chime speechd-up[456446]: Starting speechd-up... Mar 05 20:48:08 chime speechd-up[456446]: To work, speechd-up needs speakup and speakup_soft modules. Mar 05 20:48:08 chime speechd-up[456446]: They are loaded automatically. If you don't want, type Mar 05 20:48:08 chime speechd-up[456446]: rmmod speakup
Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
On Mon, 14 Mar 2022, Simon McVittie wrote: > Please could the BTS owners provide or approve a clearer wording for > this, if they are the "owners" of the tag definition? [...] I'm open to any inclusive language which you all agree on. The point of the tag was to help highlight bugs which impacted the usability of an application by someone who was using assistive (or other adaptive) technology to use an application/package/system. [So things like screen readers, dyslexia fonts, braille ttys, predictive input devices, etc. (definitely not an exclusive list of categories, of course).] I'd like if it includes "accessibility" in the language (so someone can figure out why it's called a11y), but I'm happy with any language that are acceptable to advocates and the community affected by these issues. -- Don Armstrong https://www.donarmstrong.com A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia
Speech-Dispatcher Won't Install
Hi All: I hope I am subscribed to this list, as it was suggested by Paul, who's name was in a README of this package. Anyway, I am trying to get newer embedded voices from Voxin running in a Debian SID 5.16.0-3 system. A version of speechd-up which tries to install is 0.5 from Brailcom. But even compiling provides similar results. Errors were encountered while processing: speechd-up E: Sub-process /usr/bin/dpkg returned an error code (1) Folks who maintain-and-use Voxin say I must run "speechd-up" instead of "voxinup" Right now I am still listening to speech from a DecTalk but would like to enjoy Allison from these newer voices through Speakup. Thanks so much in advance Chime
Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
Chime Hart, le lun. 14 mars 2022 11:28:33 -0700, a ecrit: > I would vote for the phrase "special needs" instead of any form of disabled, > as it would seem more of a positive. I understand that point of view. But then people will add the tag, saying "I have a special need: I want to drive 3 screens at a time", and whatnot :) Samuel
Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
Simon McVittie, le lun. 14 mars 2022 18:21:41 +, a ecrit: > "This bug particularly affects users with disabilities" > if we're using a form of wording similar to that, because what we're > interested in is whether a bug is *particularly* significant for users > of accessibility technologies etc. Yes, that's it! > rather than just any random bug that happens to have been encountered > by a user with a disability. Nope :) Samuel
Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
I would vote for the phrase "special needs" instead of any form of disabled, as it would seem more of a positive. Thank you Chime
Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
On Mon, 14 Mar 2022 at 09:38:36 -0400, Sandro Tosi wrote: [ Simon McVittie wrote: ] > > My understanding is that the a11y tag is intended to be for bugs that > > harm Debian's usefulness for people who rely on assistive technologies > > (screen readers, high contrast themes, etc.), and more generally, people > > who are not well-served by typical application developer assumptions as > > a result of disabilities or similar factors. The debian-accessibility > > mailing list is described on https://lists.debian.org/devel.html as > > "Making Debian more accessible to people with disabilities", and the > > a11y tag is shown on bugs.debian.org as a wheelchair symbol emoji, > > which supports that interpretation. > > > > However, reportbug describes the tag as: > > > > > 1 a11y This bug is relevant to the accessibility of the package. > > > > and I think a lot of non-technical users are interpreting this as "this > > bug makes it hard for *me personally* to use this package" - but if > > we used that interpretation, then it would apply to a lot of medium to > > high severity bugs in user-facing components like desktop environments, > > and the bugs that are particularly relevant to debian-accessibility > > subscribers would be lost in the noise. > > I sympathize with your request, but please first address the rewording > the the authoritative source of tags descriptions: > https://www.debian.org/Bugs/Developer#tags Please could the BTS owners provide or approve a clearer wording for this, if they are the "owners" of the tag definition? In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007106#10, Samuel Thibault suggested "This bug is relevant to the accessibility of the package for disabled users." or "This bug affects disabled users." and in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007106#20, Cindy Sue Causey suggested "... affects people with disabilities." or "... affects users with disabilities." I would personally say "This bug particularly affects users with disabilities" if we're using a form of wording similar to that, because what we're interested in is whether a bug is *particularly* significant for users of accessibility technologies etc., rather than just any random bug that happens to have been encountered by a user with a disability. Thanks, smcv
Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
On 3/14/22, john doe wrote: > On 3/14/2022 12:53 AM, Samuel Thibault wrote: >> Hello, >> >> Simon McVittie wrote: >>> Can anyone suggest a wording that makes the intention of the tag >>> clearer, >>> without "othering" the people who particularly need bugs with this tag >>> to >>> be fixed? I've cc'd debian-accessibility in the hope that someone on >>> that >>> list has a better idea. >> >> Thanks for the notice! >> >>> 1 a11y This bug is relevant to the accessibility of the package. >> >> Perhaps simply adding >> >> 1 a11y This bug is relevant to the accessibility of the package for >> disabled users. >> >> ? >> >> Or rephrasing to make it shorter: >> >> 1 a11y This bug affects disabled users. >> > > Or an alternative: > > 1 a11y This tag refers to peoples with disabilities > > Would be nice if native English speakers could help properly phrasing > this! :) ... affects people with disabilities. ... affects users with disabilities. It's called "person (or people) first language" where self-advocates ask to be recognized first before their disability. Dear friends in Atlanta, Georgia, and elsewhere were instrumental in helping it gain traction exactly when the following acknowledges as a date of reference: https://odr.dc.gov/page/people-first-language And I just learned something new k/t this thread. There is also "identity first language" that understandably evolved as a result: https://accessate.net/features/2519/person-first-vs-identity-first-language My takeaway is "users with disabilities" remains an accepted, respectful umbrella for all disabilities. If this was only about one specific disability, there may be an alternative that each disability has voiced is preferable to them. Of note: There are times when it's tough to fulfill "person first" fully due to the limitations of e.g. social media's occasional 280-character limitations per post. Cindy :) -- * runs with birdseed *
Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
On 3/14/2022 12:53 AM, Samuel Thibault wrote: Hello, Simon McVittie wrote: For instance, the bug that prompted me to open this one is a deadlock (or something) in interacting with Pipewire's PulseAudio-compatible server, which makes the game Minetest (among others) take a long time to start and have no sound. That certainly makes it hard to access normal functionality of minetest, but it doesn't seem like a bug that needs particular attention from accessibility experts... Oops, indeed! Can anyone suggest a wording that makes the intention of the tag clearer, without "othering" the people who particularly need bugs with this tag to be fixed? I've cc'd debian-accessibility in the hope that someone on that list has a better idea. Thanks for the notice! 1 a11y This bug is relevant to the accessibility of the package. Perhaps simply adding 1 a11y This bug is relevant to the accessibility of the package for disabled users. ? Or rephrasing to make it shorter: 1 a11y This bug affects disabled users. Or an alternative: 1 a11y This tag refers to peoples with disabilities Would be nice if native English speakers could help properly phrasing this! :) -- John Doe
