Re: Exim4 in Debian?
Chime Hart, le ven. 26 avril 2024 11:31:35 -0700, a ecrit: > And just curious, are their any Debian distros which have later > kernels like Arch? You cannot have the latest bleeding edge without bleeding. Really, leave a bit of time to software, and you'll suffer less. Samuel
Re: Exim4 in Debian?
Hello, Chime Hart, le ven. 26 avril 2024 10:23:33 -0700, a ecrit: > I am noticing here in Debian SID that packages I use > regularly are mysteriously vanishing. SID is what it is: unstable. At the moment there is a huge upgrade to 64bit time_t which makes various packages non-installable, and thus apt has a hard time finding another solution than just removing packages. If you don't want instability, please use the testing distribution. Samuel
Re: [BRLTTY] Graphical BRLTTY running but not used in terminals
Sébastien Hinderer, le mar. 26 mars 2024 13:40:48 +0100, a ecrit: > I think what mislead me is that, although the braille rendering isdone > by BRLTTY, there continues to be a speech rendering which, I think, _is_ > done by Orca. That's entirely possible, since Orca doesn't even know that brltty is reading it. You probably want to set a per-app preference to disable speech in terminal. Samuel
Re: [BRLTTY] Graphical BRLTTY running but not used in terminals
Hello, Sébastien Hinderer, le mar. 26 mars 2024 12:00:58 +0100, a ecrit: > I think my graphical Mate terminals are rendered by Orca, whereas I do > see a graphical BRLTTY process, run with the command > > /bin/brltty -b ba -s no -x a2 -N > > I assume there is a priroity issue between two BrlAPI clients. AFAIK, the latest released versions of orca and brltty handle it correctly: usually Orca uses the default priority (50), except in flat review mode, in which case it uses a higher priority (70). On the brltty side, the a2 screen reader reports SCQ_GOOD for the terminal case, which translates to default+10, so 60, so it'd be higher than what orca sets. Samuel
Re: best way to change speakup defaults in debian automatically when the system boots into console mode
Frank Carmickle wrote: > Samuel, would it be a good idea to add a check for the existence of > speakupconf in the espeakup systemd unit, and if it exists, load the config? Ideally it'd stay within the speakup-tools package. And we need to make sure this gets started at the proper time, i.e. not before the speakup module is loaded. I have tried putting the script call into /etc/modprobe.d/ with an install line, and it works fine, I'll upload that. Samuel
orca 46 beta
Hello, I have uploaded orca 46 beta to experimental. So please test and report to the orca list ;) Samuel
Re: Please test brltty 6.6-4+exp1 from experimental
Hello, Samuel Thibault, le dim. 18 févr. 2024 01:32:35 +0100, a ecrit: > I have uploaded to experimental version 6.6-4+exp1 of brltty that does > so, it works for me but better get more tests before uploading to > unstable, so please help with this :) Sebastien reminds me that you need to take care, when installing the version from experimental, to also install other brltty packages such as brltty-x11, otherwise apt may want to remove them. You can also use: apt -t experimental brltty to tell apt to possibly get other packages from experimental. Samuel
Please test brltty 6.6-4+exp1 from experimental
Hello, With Trixie supporting only merged-usr systems, we have to move files to /usr in the packages themselves. I have uploaded to experimental version 6.6-4+exp1 of brltty that does so, it works for me but better get more tests before uploading to unstable, so please help with this :) Samuel
Re: Dialog for dpkg-based package configuration
Hello, Sebastian Humenda, le jeu. 08 févr. 2024 17:56:54 +0100, a ecrit: > On my system for daily use, I can use dialog-based configuration UIs just fine > (BRLTTY). It was installed using the accessible Debian installer. > An example is `dpkg-reconfigure locales'. > > However, in a cloud setting, I am working with temporary containers that I set > up using a script. When installing locales, the shown dialog is not using the > "real" TTY cursor, but visual highlighting. > Which setting, probably set by the installer, changes this behaviour? It is just a difference between the dialog and the whiptail implementations. Install whiptail, and you'll be good. Samuel
Re: I Am Trying to File A Bug?
Hello, Chime Hart, le mer. 31 janv. 2024 19:51:22 -0800, a ecrit: > Hi All: As I was working through reportbug, it asks me for tags? Well, no > matter how I write them, How did you try to write them? > Maybe instead of a cryptic "invalid entry" it would be > more helpful mentioning what items are missing. reportbug does start with giving a list of the most useful tags, including some shortcut numbers that can be used as well. Samuel
Re: Accessible terminal output
Niels Thykier, le sam. 27 janv. 2024 23:10:08 +0100, a ecrit: > Samuel Thibault: > > One thing that is important for the screen reader to know what to render > > is to put the caret on the item that matters. > > I have trouble with this one. Can you provide an example that would work in > the terminal or a command that does this well? It wholy depends on how you emit your output. In curses terms it's a question of using move() to set the coordinates of the carte. Samuel
Re: Accessible terminal output
Hello, Giving a very small answer here. Niels Thykier, le sam. 27 janv. 2024 22:18:23 +0100, a ecrit: > Like should the tool disable > ANSI color and boldface output to avoid creating confusing output? Screen readers just ignore colors & bold/italic :) One thing that is important for the screen reader to know what to render is to put the caret on the item that matters. Samuel
Re: brltty input monitor error 19
Hello, Colomban Wendling, le mer. 24 janv. 2024 12:54:36 +0100, a ecrit: > A client of mine is having trouble with brltty sometimes heavily spamming > the logs with "braille input monitor error 19: No such device", and I'm > wondering what this could actually mean is the trouble. I'd say ask the brltty mailing list. We probably want Dave to add more information on the actual input device that poses problem. Possibly we can then filter out such kind of input, or at least understand the condition in which this does happen (possibly something that gets unplugged by the user), and react properly. At least, the brltty mailing list will probably know more if it was seen previously :) Samuel
Re: orca 46 alpha
Sebastian Humenda, le dim. 21 janv. 2024 16:47:09 +0100, a ecrit: > Samuel Thibault schrieb am 21.01.2024, 11:43 +0100: > >Sebastian Humenda, le dim. 21 janv. 2024 11:33:42 +0100, a ecrit: > >> Samuel Thibault schrieb am 20.01.2024, 23:35 +0100: > >> >I have uploaded orca 46 alpha to experimental. It is notably said to > >> >have improved performance a lot through using cache.o > >> Sounds great, thanks for giving the opportunity to test it out. > >> Are there any minimum required software versions of involved components? > > > >Ah, yes, you need at-spi2-core >= 2.50, it's available as backport. > > It still doesn't start with the same debug output. I would probably need an > unstable system to test things properly. Or has anyone tried it successfully > on Bookworm? I gave a try, you need to upgrade gir1.2-atspi-2.0 to 2.50 as well. Samuel
Re: orca 46 alpha
Sebastian Humenda, le dim. 21 janv. 2024 11:33:42 +0100, a ecrit: > Samuel Thibault schrieb am 20.01.2024, 23:35 +0100: > >I have uploaded orca 46 alpha to experimental. It is notably said to > >have improved performance a lot through using cache.o > Sounds great, thanks for giving the opportunity to test it out. > Are there any minimum required software versions of involved components? Ah, yes, you need at-spi2-core >= 2.50, it's available as backport. Samuel
orca 46 alpha
Hello, I have uploaded orca 46 alpha to experimental. It is notably said to have improved performance a lot through using cache. It also got significant rewrites to clear the code, so there may be regressions ahead. So please test and report to the orca list ;) Samuel
Re: espeakup stops speaking bookworm arm64
Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit:
> On Thu, 4 Jan 2024, Samuel Thibault wrote:
>
> > Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit:
> > > On Thu, 4 Jan 2024, Samuel Thibault wrote:
> > >
> > > > Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:
> > > > > On Wed, 3 Jan 2024, Samuel Thibault wrote:
> > > > >
> > > > > > This confirms that "the impossible" has happened :)
> > > > > >
> > > > > > The alsa-lib lock reports a mutex being held by a thread that is not
> > > > > > actually running alsa-lib functions.
> > > > > > {snip}
> > > > You can also as well just download the .deb file :)
> > > >
> > > I see that you also have libespeak-ng1-dbgsym
> > >
> > > Would you like me to install that too?
> >
> > That'll be useful for gdb debugging, but not to check whether it works
>
> It didn't.
Ok :/
> I updated the core file at http://quitelikely.com/gcore
Thanks, that's indeed still the same situation: an alsa-lib mutex is
said to be held by a thread which is not executing alsa-lib code.
Are you perhaps running some particular alsa configuration?
Samuel
Re: espeakup stops speaking bookworm arm64
Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit: > On Thu, 4 Jan 2024, Samuel Thibault wrote: > > > Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit: > > > On Wed, 3 Jan 2024, Samuel Thibault wrote: > > > > > > > This confirms that "the impossible" has happened :) > > > > > > > > The alsa-lib lock reports a mutex being held by a thread that is not > > > > actually running alsa-lib functions. > > > > > > > I looked at the ReadMe on your site and it said to run the following to > > > import your apt key: > > > > > > sudo apt-key adv --recv-keys --keyserver keyring.debian.org > > > 900CB024B67931D40F82304BD0178C767D069EE6 > > > > > > But when I try, I get the following error: > > > > > > Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d > > > instead (see apt-key(8)). > > > Executing: /tmp/apt-key-gpghome.N9pKWsZ2Uo/gpg.1.sh --recv-keys > > > --keyserver > > > keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6 > > > gpg: keyserver receive failed: Server indicated a failure > > > > Uh? It does work here. > > Interesting... > > > > Is there another way that I can get your key? > > > > Here it is, you can use apt-key add /tmp/sthibault.gpg > > I just copied it into /etc/apt/trusted.gpg.d as instructed by apt-key(8). > > > You can also as well just download the .deb file :) > > > I see that you also have libespeak-ng1-dbgsym > > Would you like me to install that too? That'll be useful for gdb debugging, but not to check whether it works :) Samuel
Re: espeakup stops speaking bookworm arm64
Hello, Geoff Shang, le mar. 02 janv. 2024 15:33:20 +0200, a ecrit: > On Mon, 1 Jan 2024, Samuel Thibault wrote: > > > Hello, > > > > Geoff Shang, le lun. 01 janv. 2024 18:39:33 +0200, a ecrit: > > > On Sun, 31 Dec 2023, Samuel Thibault wrote: > > > > Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: > > > > > On Dec 29, 2023, at 15:54, Samuel Thibault > > > > > wrote: > > > > > > > #4 0x7fbedbb1a006 in snd_pcm_state () from > > > > > > > /lib/x86_64-linux-gnu/libasound.so.2 > > > > > > > No symbol table info available. > > > > > > > #9 0x7fbedb7fd872 in alsa_object_close () from > > > > > > > /lib/x86_64-linux-gnu/libpcaudio.so.0 > > > > > > > No symbol table info available. > > > > > > > > > > > > Would you be able to reproduce with these packages installed? > > > > > > > > > > > > libpcaudio0-dbgsym > > > > > > libasound2-dbgsym > > > > > > > > > > I have done, as Geoff has done, with these additional symbols. > > > > > > > > Was that really in the stuck case? Your traces don't show anything that > > > > seems to be stuck. > > > > > > Try this. > > > > Thanks! This is indeed the stuck condition I was looking for. > > > > I'm still baffled how we can end up in such a condition, I'd need to be > > able to perform more investigation. Perhaps you can trigger a core file > > generation by telling to gdb: > > > > generate-core-file /tmp/gcore > > > > and put it somewhere on the Internet for me to fetch it? > > http://quitelikely.com/gcore > > It's 300 mb. Thanks! This confirms that "the impossible" has happened :) The alsa-lib lock reports a mutex being held by a thread that is not actually running alsa-lib functions. I however noticed that espeak-ng uses pcaudiolib without any locking, and pcaudiolib is definitely not threadsafe. On https://people.debian.org/~sthibault/tmp/bookworm-tmp I have put some libespeak updates (version 1.51+dfsg-10+pcaudioliblock) that add locking, could try to install libespeak-ng1 from there, and see if you can still reproduce the issue? Samuel
Re: espeakup stops speaking bookworm arm64
Hello, Geoff Shang, le lun. 01 janv. 2024 18:39:33 +0200, a ecrit: > On Sun, 31 Dec 2023, Samuel Thibault wrote: > > Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: > > > On Dec 29, 2023, at 15:54, Samuel Thibault wrote: > > > > > #4 0x7fbedbb1a006 in snd_pcm_state () from > > > > > /lib/x86_64-linux-gnu/libasound.so.2 > > > > > No symbol table info available. > > > > > #9 0x7fbedb7fd872 in alsa_object_close () from > > > > > /lib/x86_64-linux-gnu/libpcaudio.so.0 > > > > > No symbol table info available. > > > > > > > > Would you be able to reproduce with these packages installed? > > > > > > > > libpcaudio0-dbgsym > > > > libasound2-dbgsym > > > > > > I have done, as Geoff has done, with these additional symbols. > > > > Was that really in the stuck case? Your traces don't show anything that > > seems to be stuck. > > Try this. Thanks! This is indeed the stuck condition I was looking for. I'm still baffled how we can end up in such a condition, I'd need to be able to perform more investigation. Perhaps you can trigger a core file generation by telling to gdb: generate-core-file /tmp/gcore and put it somewhere on the Internet for me to fetch it? Thanks, Samuel
Re: espeakup stops speaking bookworm arm64
Hello, Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: > On Dec 29, 2023, at 15:54, Samuel Thibault wrote: > > Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit: > >> On Thu, 21 Dec 2023, Samuel Thibault wrote: > > This is showing that it's alsa-lib which gets stuck. I tried to dive > > into the source code, but I don't see yet how that can happen, a quick > > review showed me that locking seems to be done properly. I'd probably > > need a closer look since the hang *does* happen. > > > >> #4 0x7fbedbb1a006 in snd_pcm_state () from > >> /lib/x86_64-linux-gnu/libasound.so.2 > >> No symbol table info available. > >> #9 0x7fbedb7fd872 in alsa_object_close () from > >> /lib/x86_64-linux-gnu/libpcaudio.so.0 > >> No symbol table info available. > > > > Would you be able to reproduce with these packages installed? > > > > libpcaudio0-dbgsym > > libasound2-dbgsym > > I have done, as Geoff has done, with these additional symbols. Was that really in the stuck case? Your traces don't show anything that seems to be stuck. Samuel
Re: espeakup stops speaking bookworm arm64
Hello, Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit: > On Thu, 21 Dec 2023, Samuel Thibault wrote: > > > thread apply all bt full > > > > :) > > OK, you got it. > > This produced 20 kb of output, so I've attached it. Let me know if anyone > wants it included in the message instead. Attached is completely fine, thanks a lot! This is showing that it's alsa-lib which gets stuck. I tried to dive into the source code, but I don't see yet how that can happen, a quick review showed me that locking seems to be done properly. I'd probably need a closer look since the hang *does* happen. > #4 0x7fbedbb1a006 in snd_pcm_state () from > /lib/x86_64-linux-gnu/libasound.so.2 > No symbol table info available. > #9 0x7fbedb7fd872 in alsa_object_close () from > /lib/x86_64-linux-gnu/libpcaudio.so.0 > No symbol table info available. Would you be able to reproduce with these packages installed? libpcaudio0-dbgsym libasound2-dbgsym Thanks, Samuel
Re: espeakup stops speaking bookworm arm64
Geoff Shang, le jeu. 21 déc. 2023 18:50:52 +0200, a ecrit: > On Thu, 21 Dec 2023, Samuel Thibault wrote: > > > All we need now is the full > > > > thread apply bt full > > > > to get the most available information. > > Earlier you said to use > > thread apply all bt > > Which do you want? thread apply all bt full :) Samuel
Re: espeakup stops speaking bookworm arm64
Frank Carmickle, le jeu. 21 déc. 2023 08:39:31 -0500, a ecrit: > On Dec 20, 2023, at 18:34, Samuel Thibault wrote: > > > > James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit: > >> sthibault: do you think this could be related to > >> https://github.com/linux-speakup/espeakup/pull/48 ? > > > > Possibly. Testing would give a definite answer. > > > >>>> It took me a couple of goes, and I lost speech entirely both times (not > >>>> sure why), but I got a trace. > >>>> > >>>> I'm not sure how helpful it is though. > >>>> > >>>> 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > >>>> (gdb) bt > >>>> #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > >>>> #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > >>>> #2 0x5605c505e734 in main (argc=, argv= >>>> out>) > >>>> at ../src/espeakup.c:229 > > > > To get useful information, the libc6-dbg package should be installed, > > and this should be used: > > > > thread apply all bt > > I have installed > > > > Reading symbols from /usr/bin/espeakup... > Reading symbols from > /usr/lib/debug/.build-id/7c/ee622ad29eb52a84ecd41e5e9cb868d8d27eef.debug... > Attaching to program: /usr/bin/espeakup, process 63456 > [New LWP 63457] > [New LWP 63458] > [New LWP 63459] > [New LWP 63460] > --Type for more, q to quit, c to continue without paging--c > [New LWP 63461] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". > 0xb81bb694 in __futex_abstimed_wait_common64 (private=128, > cancel=true, abstime=0x0, op=265, expected=63457, > futex_word=0xb74cf1b0) at ./nptl/futex-internal.c:57 > 57 ./nptl/futex-internal.c: No such file or directory. > (gdb) > > What am I missing? It's completely fine that it doesn't have the .c files: I do have them :) "__futex_abstimed_wait_common64" and "./nptl/futex-internal.c:57" are the pieces of information that we do need, the details of the .c files we can work by ourself, provided that we know the versions of the libc6, libespeak-ng1, and espeakup packages. All we need now is the full thread apply bt full to get the most available information. Samuel
Re: espeakup stops speaking bookworm arm64
James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit: > sthibault: do you think this could be related to > https://github.com/linux-speakup/espeakup/pull/48 ? Possibly. Testing would give a definite answer. > > > It took me a couple of goes, and I lost speech entirely both times (not > > > sure why), but I got a trace. > > > > > > I'm not sure how helpful it is though. > > > > > > 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > > (gdb) bt > > > #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > > #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > > #2 0x5605c505e734 in main (argc=, argv= > > out>) > > >at ../src/espeakup.c:229 To get useful information, the libc6-dbg package should be installed, and this should be used: thread apply all bt Samuel
Re: Embossing via cups, braille translation does not work
Hello,
Sebastian Humenda, le mar. 19 déc. 2023 08:22:11 +0100, a ecrit:
> Where can I access the logs to see where the translation possibly fails? In
> /var/log/cups/{error|access}.log is nothing useful.
That's the place, but you'll want to raise in /etc/cups/cupsd.conf the
LogLevel to debug.
> While reading error.log, I stumlbed over this:
>
> W [19/Dec/2023:07:27:36 +0100] Printer drivers are deprecated and will
> stop working in a future version of CUPS. See
> https://github.com/OpenPrinting/cups/issues/103
>
> Would this affect the cups filters?
Not for now.
Samuel
Re: debian testing iso install in franch: mate desktop is in English
Hello, Jérémy Prego, le ven. 15 déc. 2023 19:45:05 +0100, a ecrit: > a friend and I installed a debian testing from the iso available here: > https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/ > > When you choose French, and install the mate desktop, the graphical > interface is in English, while the rest of the system is in French. For such not-accessibility-related issues, better report a bug to debian-boot, where the actually competent people will be able to read it. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, This is all very odd. Jason J.G. White, le mar. 14 nov. 2023 08:56:27 -0500, a ecrit: > > On 14/11/23 08:35, Christian Schoepplein wrote: > > After installing the two gir packages with the fix from your personal repo > > all things are good again: > > You'll need to mark the appropriate libvte packages as on hold until Samuel's > patch is accepted upstream, and the upstream version enters Debian. Otherwise, > Samuel's packages will be replaced every time a new upstream version enters > the > repository you're using. The debian package 0.74.1-1 does contain my fix as kindly patched by the debian maintainer, Jeremy Bicha. So the Debian package is supposed to provide the same fix as my package. Christian, can you confirm by running zgrep libvte-2.91-0 /var/log/dpkg.log. that the libvte-2.91-0 package (which really contains the binary built with my patch) was upgraded before you noticed the issue? And thus it's really *exactly* the upgrade of the gir packages that brought the issue? (which is really odd since gir packages don't ship implementations, they just provide interfaces) Samuel
Re: Request for archive data
Hello, Shrabani Ghosh, le jeu. 09 nov. 2023 15:48:17 -0500, a ecrit: > I am Shrabani Ghosh, a PhD student. I would like to request to give me > directions for downlaoding Debian mailing list archives. > I would create a graph from the mailing list for my research purpose. You should probably contact listmas...@lists.debian.org Samuel
Re: Will be the new Raspberry pi os accessible under Wayland?
Hello, Pavel Vlček, le lun. 23 oct. 2023 10:39:34 +0200, a ecrit: > will this version be accessible with Orca? As much as Orca can access applications with wayland, yes: there will be e.g. the missing keyboard handling, coordinates positioning, etc. Now, whether Raspberry pi OS enables accessibility in the graphical sessions, I don't know. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello,
Interesting... So it's tmux as source which poses problem,
for whatever reason. And you don't have a /etc/tmux.conf or a
~/.config/tmux/tmux.conf?
Christian Schoepplein, le mer. 25 oct. 2023 09:50:26 +0200, a ecrit:
> If I open a tmux session and copy multiline content from this session with
> the new flatfview feature from orca and not with brltty's COPY_RECT feature
Ok, how do you copy from orca exactly? The
FLAT_REVIEW_COPY = _("Copy the contents under flat review to the clipboard")
Orca command? Or braille routing keys?
Could you kill your xbrlapi, then try to run
xbrlapi -v -n 2> log
then perform the failing copy/paste, and send us the log?
Also, could you try if you can reproduce the issue with orca without
xbrlapi running?
Samuel
Re: Location of liblouis translation tables
Sebastian Humenda, le mer. 25 oct. 2023 18:05:41 +0200, a ecrit: > Samuel Thibault schrieb am 25.10.2023, 14:22 +0200: > >Sebastian Humenda, le lun. 16 oct. 2023 02:16:34 +0200, a ecrit: > >> Any ideas? > > > >It seems some changes in the tables file broke cups-filter's ability to > >find them. Could you try to change in > > > >/usr/share/cups/braille/cups-braille.sh > > > >locale: > > > >into > > > >language: > > I expect you meant `locale:` within the if and elif? Yes. > I've selected "default for language, grade 2" in the web interface and > it seems indeed to work. Ok, good :) > The error log now contains other errors: > > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:35 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > E [25/Oct/2023:17:57:36 +0200] [Job 10] unsupported control character in BRF > file > > I have been trying to print a standard HTML file (plain HTML, no js, etc.). I don't remember how that's supposed to convert. You probably want to raise the cups log level to see more details on the conversion process. Samuel
Re: Location of liblouis translation tables
Hello, Sebastian Humenda, le lun. 16 oct. 2023 02:16:34 +0200, a ecrit: > I've set up the cups filters to print with my Index Everest V5. > The Cups interface shows an error when I try to print: > "Could not find LibLouis table with locale de_DE" > I've installed these packages: > liblouis-bin liblouis-data liblouis20 liblouisutdml-bin liblouisutdml-data > liblouisutdml9 liblouisxml-bin liblouisxml-data liblouisxml1 > > Any ideas? It seems some changes in the tables file broke cups-filter's ability to find them. Could you try to change in /usr/share/cups/braille/cups-braille.sh locale: into language: ? I'll try to get that fixed in bookworm's cups-filters, since the patch is very trivial. > I have also seen that there seem to be official Index drivers these days in > printer-driver-indexbraille. Has anyone tried them out? That driver just sends the document to the embosser, and lets the embosser perform all conversions etc. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Please answer all questions :) What do you get when you paste into another graphical application such as pluma or gedit? And conversely when pasting into tmux? Christian Schoepplein, le mar. 24 oct. 2023 17:07:59 +0200, a ecrit: > I've also tested it with the new show flatview contents feature of orca 45 > during working in a tmux session. There the same issue is happening if I > copy multiline text and insert it using different editors. I don't see the relation between flatview and copy? Are you using a copy feature from orca? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Samuel Thibault, le dim. 22 oct. 2023 22:36:34 +0200, a ecrit: > Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: > > The issue is with copying content via the cliphboard feature of brltty if I > > am inside a tmux session which I need to use very ofthen for my daily job. > > > > The original content I like to copy looks like this: > > > > borg_backup_client_exclude_host_specific: > > - /rpool > > - /tank > > Does it happen with whatever kind of content, or is it specific to this > kind of content? Is this showing up in an editor? (which editor?) or as > output of a command? Also, I forgot: are you using COPY_LINE or COPY_RECT? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: > The issue is with copying content via the cliphboard feature of brltty if I > am inside a tmux session which I need to use very ofthen for my daily job. > > The original content I like to copy looks like this: > > borg_backup_client_exclude_host_specific: > - /rpool > - /tank Does it happen with whatever kind of content, or is it specific to this kind of content? Is this showing up in an editor? (which editor?) or as output of a command? > Outside a tmux session copying this content works quite well. But inside a > tmux session I get this when inserting the textblock into another file: Into what are you pasting? An editor? (which editor?) What do you get when you paste into another graphical application such as pluma or gedit? And conversely when pasting into tmux? Samuel
Re: Mac mini 2014 will not show Debian installer grub menu.
Hello, Note that you need to select the graphical boot entry in order to get speech support. Beeping might not be supported on the mac mini, but if it's grub, the "s" shortcut should be working. Samuel
Re: Unable to install Debian 12 in dark mode
Hello, Kenneth Schack Banner, le jeu. 19 oct. 2023 12:20:35 +0200, a ecrit: > I boot it up, when boot menu comes up, i selected dark mode (4. og 5. > option) and then the graphical installer front end. Ok. > Then i navigate around urisng the arrows, but when i get to where i select > the desktop enovierment etc. i found it, i need to use the tabulator to get > down to the confinue button. Yes. > I just dont understand why it first then has to > use tabulator key, when i untill then was able just to use the arrows. I actually I'm even surprised that arrows are enough for most of the installer. The tab key is really the usual way to switch between widgets. Samuel
Re: Problems with cursor routing and copy/paste in BRLTTY
Odd Martin Baanrud, le mer. 18 oct. 2023 14:45:05 +0200, a ecrit: > > On 29 Sep 2023, at 23:41, Samuel Thibault wrote: > > > > Linux indeed broke TIOCSTI for brltty. The fix is under way, it'll get > > into Debian 12's backport eventually (linux 6.4.8). > > Do you know when it’s ready? "when it's ready." I'm not in the kernel team so I can't answer anyway, but I guess the answer would be the same. > If it take som time, how can I revert to the release kernel, without having > to disable backports all together? backports don't upgrade automatically, so you can just reinstall the non-backport kernel and remove the backport kernel, and the latter won't come back automatically. Samuel
Re: Unable to install Debian 12 in dark mode
Hello, Kenneth Schack Banner, le mar. 17 oct. 2023 21:45:17 +0200, a ecrit: > I wanted to install Debian 12 on a Intel NUC Celeron N5105, but seems to > have hit a wall during installation. > > When i get to the point where i can choose a desktop enoviremt, ssh server, > internet service etc. i am not able to continue.. I dont know if its me, but > i press down and to the sides, but i am not able to get focus on the > "Continue" button.. Which installer frontend are you using? The textual? The graphical? > Is there a keyboard shortcut to continue in the dark mode / high contrast > graphical installer? Switching colors during installation is still in the TODO list, contribution is welcome. Samuel
Re: Braille does not follow cursor in Mate Terminal
Hello, Jason White, le mer. 11 oct. 2023 13:15:25 -0400, a ecrit: > On 11/10/23 10:50, Patrick ZAJDA wrote: > > If I open a terminal and move the review cursor, I have the content read > > by voice as expected but braille does not follow, on my braille display > > content stays the same. > > BRLTTY may be providing access to the terminal independently of Orca, which > has been supported for a while. > > Try issuing standard BRLTTY console-level commands inside the graphical > terminal. If they work, this will establish that BRLTTY is indeed providing > its own commands and features to access the terminal session. And then BRLTTY indeed cannot know at all about Orca's review cursor, it can only know about the real cursor. Perhaps Orca should, when using flat-review, increase its braille output priority, so as to take over the BRLTTY output. That should be discussed on the orca list, not the debian list. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le ven. 06 oct. 2023 20:52:20 +0200, a ecrit: > On Mon, Sep 11, 2023 at 02:27:41AM +0200, Samuel Thibault wrote: > > > >I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an > >improved patch. Could people try it? I have also uploaded patched Debian > >packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ > > I was on vacation for three weeks and updated my Debian testing system > today. Also the libvte packages have been updated to a newer version, 0.74, > and the packages with all fixes from your repo, Samuel, Which exact version are you testing? Please use dpkg -l libvte-2.91-0:amd64 otherwise I cannot say anything about your results. My package with latest changes is versioned 0.73.99-1+fix, not 0.74. > I took a look at the bug report and into the changelogs, but its not really > clear to me, if the fixes are included in the 0.74 version now or if they > are still not included. They are not. > Whats the current state of the bug? We are waiting for feedback to make sure that things are fixed without introducing regressions. > Can I somehow install the old 0.73 packages from your repo, Sure, see the readme file. > Samuel, or can you provide the 0.74 packages with the fix please or > shall I try to build the new packages myself and include the patch? No need to build anything, just pick up my packages. Samuel
Re: Problems with cursor routing and copy/paste in BRLTTY
Hello, Odd Martin Baanrud, le ven. 29 sept. 2023 23:03:22 +0200, a ecrit: > I’m running Debian 12, with backports enabled. > For some time, cursor routing and copy/paste in BRLTTY has not worked. > When I press a cursor routing key, or try to paste something from the BRLTTY > buffer, I get the following message: > “Linux character injection (TIOSCSTI) is disabled on this system” > What does that mean? Linux indeed broke TIOCSTI for brltty. The fix is under way, it'll get into Debian 12's backport eventually (linux 6.4.8). Samuel
Re: java atk wrapper in bookworm
Sam Hartman, le mar. 26 sept. 2023 08:20:31 -0600, a ecrit: > I'm still very confused by all this. > Is this an Oracle issue or an Ubuntu issue or a Debian Java maintainer > issue. It really is an Oracle issue, and Debian/Ubuntu has brown-tape-fixed it since Oracle wasn't understanding the issue. But like all brown-tape fixes, it eventually broke so Debian/Ubuntu dropped the fix. Samuel
Re: java atk wrapper in bookworm
Halim Sahin, le mar. 26 sept. 2023 11:30:13 +0200, a ecrit: > Samuel wrote that ubuntu has removed a patch which is needed to load > atk-wrapper into jre. > > openjdk-17 has the mentioned issue > openjdk-19-jre:amd64 works as expected regarding atk-wrapper. > tested on a machine running ubuntu 22.04. > > Was the patch only removed for jre-17? Apparently, it is indeed still there in jre-19. In debian it seems it got removed in jre-21 too, it'll probably get dropped in other versions as well. Samuel
Re: java atk wrapper in bookworm
Sam Hartman, le mar. 19 sept. 2023 08:15:35 -0600, a ecrit: > But I think you will be more likely to get that if you can clearly > articulate the situation. The simple answer is that it just does not work when using the debian- (or ubuntu-) provided packages. And that is the scenario that I was reporting. I have no idea what package they actually used to "reproduce" my scenario. My best guess is that they either used their own build that might be include some patch that happens to fix the issue. Or that they didn't manage to actually enable the atk bridge (so as to actually see the load failure). But I didn't get any answer from Oracle when I gave them the exact details of what I was doing with ubuntu-only packages. And at this point I don't think I can hope to see them actually try to run orca and see that java applications are just not accessible. I mean, they asked for a reproducer application. That just shows that they don't actually understand what "accessible" means, since it's all java applications which are impacted. Without an actual accessibility contact, I don't see how we can get things through. Samuel
Re: java atk wrapper in bookworm
Halim Sahin, le mar. 19 sept. 2023 11:23:08 +0200, a ecrit:
> After bookworm was released something is wrong on my machine or in bookworm.
> When I enable
> assistive_technologies=org.GNOME.Accessibility.AtkWrapper
> in accessibility.properties
> My Application doesn't start any more.
> The error is that it can't find the needed stuff of libatk-wrapper.
Ewww:
openjdk-17 (17.0.7+7-1) unstable; urgency=high
* drop d/p/{jaw-classpath.diff, jaw-optional.diff}: the atk wrapper
is disabled and these patches cause class data sharing tests to
fail. LP: #2016194.
https://bugs.launchpad.net/ubuntu/+source/openjdk-17/+bug/2016194?comments=all
Without *any* coordination with us.
I'm just fed up with java. Oracle didn't manage to even realize at all
that accessibility is currently just completely broken on Linux due to
this. And that's not a lack of reporting and providing reproducibility
scenarios, that's Oracle incident 9127367
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204862
Can somebody get to have a contact with Oracle about this issue? This is
not a technical issue but a political issue. As long as Oracle doesn't
actually move fingers, we'll always be on the verge of getting such
kind of unexpected regression.
Samuel
Re: Should accessibility Blend kept on Debian web pages
Hello, Andreas Tille, le dim. 17 sept. 2023 07:57:41 +0200, a ecrit: > It mentions Debian Accessibility as upcoming Blend. While I notice > you are regularly your tasks files in Git these packages were never > released. I think you mentioned before that this is not really the > plan Yes, since is not really a blend, but a collection of packages, some of which should just always be installed (for basic accessibility to be able to use the computer at all), others can be installed for particular usage (to make usage of the computer simpler). > but you like the web interface as overview for what we have. Yes, that's convenient to show what is available etc. > The question is: Should be Debian Accessibility kept on the Blends > overview page I'd say so > what would be a proper categorisation since > IMHO upcoming is not the right term for what exists since > 10 years. Indeed :) > We could move it to existing Blends since there is no rule / policy > that metapackages need to exist or remove the team from the Blends > page - whatever you prefer and think correctly describes your status. Moving to "existing" looks fine, thanks! Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Samuel Thibault, le mar. 12 sept. 2023 14:07:35 +0200, a ecrit: > Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: > > But I noticed another thing. When I switch away from the terminal, e.g. > > into > > another terminal, and then switch back into the terminal with the translate > > command everything looks good and the output is in a seperate line. > > Strange... > > Ok, I guess I see what you mean. No, I had misunderstood, I didn't realize that you were saying that the command and its output were getting glued together on the same line. Apparently brltty gets a bit confused when removing the trailing '\n'. Better be safe with screen readers and keep it always, I have updated the patches and the built package. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: > But I noticed another thing. When I switch away from the terminal, e.g. into > another terminal, and then switch back into the terminal with the translate > command everything looks good and the output is in a seperate line. > Strange... Ok, I guess I see what you mean. When a command produces more characters than the width of the terminal, they are put on a single ligne (from the point of view of brltty). When going out and coming back to the terminal, you do get separate lines split as per the width of the terminal. That's unrelated and will to be fixed another way. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit:
> The following command displays
> the output in a long line instead dividing it into seperate lines:
>
> translate -i occure
On my system it does output
Vorkommen {n} (von etw.) [min.] | Erdölvorkommen {n} | Vorkommen [...]
So it's the output of the command itself which is a one-liner, mate
can't do anything about it :)
> Also the problem that the screen content is not refreshed when deleting
> lines in a long text e.g. in the nano editor is still there. Just try the
> following:
>
> ls -1 /dev > test.txt
>
> Open the test.txt file, scrol down some pages and then delete a line with
> ctrl+k.
>
> On my machine I have to clear the screen with ctrl+l to see that the line
> has been removed on the braille display.
You mean that the braille display is still showing the very line you
wanted to remove? I am not able to reproduce this. Just to be precise:
- nano test.txt
- press page down
(get to some line shown on the braille display)
- press control-k
(the line is supposed to be replaced by the next line on the braille
display)
Do you perhaps have some particular configuration in nano?
Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit: > But there are still a few problematic things: Are these regressions over the previous state? Not that I don't want to fix them, but I want to get something committed so we can make some progress, even if not perfect yet. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le lun. 11 sept. 2023 11:38:26 +0200, a ecrit: > A way to rupture the console is to update the packages on a system with apt. > The progress line at the bottom seems to trigger the unwanted behaviour very > reproducable :-). I know, that was the original testcase that triggered opening bug #88 ;) Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: > Le 11/09/2023 à 09:01, Samuel Thibault a écrit : > > Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > > > I noticed a small problem > > > > > > 1. when you open a large file using cat file.txt |less and press enter to > > > go > > > down in the file, orca almost always pronounces the first 2 letters of the > > > line before reading the whole line. > > Is this a regression over the previous versions or not? > > yes, it's a regression. i don't have this behavior with the version in debian > testing Ok, I see the issue. I have updated the patches and package to merge the additions, could you please re-test? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le lun. 11 sept. 2023 11:38:26 +0200, a ecrit: > Just out of curiosity: Is the problem related to libvte in general or is it > related to the version in Debian? It's completely a vte bug. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: > Le 11/09/2023 à 09:01, Samuel Thibault a écrit : > > Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > > > I noticed a small problem > > > > > > 1. when you open a large file using cat file.txt |less and press enter to > > > go > > > down in the file, orca almost always pronounces the first 2 letters of the > > > line before reading the whole line. > > Is this a regression over the previous versions or not? > yes, it's a regression. i don't have this behavior with the version in debian > testing Ok, is it more problematic than the various erratic behaviors that the debian testing version has? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > I noticed a small problem > > 1. when you open a large file using cat file.txt |less and press enter to go > down in the file, orca almost always pronounces the first 2 letters of the > line before reading the whole line. Is this a regression over the previous versions or not? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an improved patch. Could people try it? I have also uploaded patched Debian packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ Please test so we can at last get this fixed! Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault, le mar. 05 sept. 2023 00:08:33 +0200, a ecrit: > Samuel Thibault, le lun. 04 sept. 2023 22:59:05 +0200, a ecrit: > > I'm on it. > > So, as usual it's the combination of two issues that were producing the > odd behavior. > [...] > So, long story short: > > https://github.com/brltty/brltty/pull/428 > > and I'll backport some fixes to bookworm. The fixed packages are in Debian stable and testing, could people make sure to upgrade and test before I upload the fixes to bookworm? Samuel
Re: orca_45~alpha-1_source.changes ACCEPTED into experimental
Hello, Orca 45 RC is now in experimental, for more testing. Samuel Samuel Thibault, le dim. 06 août 2023 23:07:25 +0200, a ecrit: > Hello, > > I have uploaded the 45-alpha version of orca to experimental, for people > to test and report issues to the orca mailing list. > > Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Chevelle, le lun. 04 sept. 2023 20:27:08 -0400, a ecrit: > Thanks Samuel. The ORCA Debian package only has xbrlapi as Reccomends. > There doesn't seem to be any warning by ORCA so if xbrlapi isn't installed > the unsuspecting user has a Braille display that doesn't work properly. > Should xbrlapi be a depends instead? No: orca doesn't depend on xbrlapi to produce its behavior. xbrlapi being a recommend already makes the xbrlapi installed by default, without making it mandatory for people who don't actually need it. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault, le lun. 04 sept. 2023 22:59:05 +0200, a ecrit: > I'm on it. So, as usual it's the combination of two issues that were producing the odd behavior. What was happening is that with xbrlapi installed but brltty-x11 not installed, the xbrlapi startup script would try to run brltty with the BrlAPI braille driver and the AtSpi2 screen driver, but the latter wouldn't load, so brltty would fallback to the "no" screen driver. But that driver was not telling the BrlAPI braille driver that it cannot do much, on the contrary it would tell that it works really well, better than Orca, and thus the BrlAPI braille driver would consume most BrlAPI keypresses. With the AtSpi2 driver installed, it knows to tell exactly when it has good support (e.g. in terminals). It happens that upgrading xbrlapi fixed this because in the newer version the xbrlapi startup script checks that both the BrlAPI and the AtSpi2 drivers are available, and not start that brltty in that case. So, long story short: https://github.com/brltty/brltty/pull/428 and I'll backport some fixes to bookworm. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 22:52:11 +0200, a ecrit: > Samuel Thibault (2023/09/04 22:42 +0200): > > Sébastien Hinderer, le lun. 04 sept. 2023 22:27:57 +0200, a ecrit: > > > Upgrade: xbrlapi:amd64 (6.5-7, 6.6-2), > > > > That makes a huge difference, that's why I was asking for versions. In > > versions before 6.6-1, the xbrlapi package was trying to start brltty > > with a ba driver and an a2 driver, only to fail loading the a2 driver. > > So possibly the presence of brltty with only the ba driver loaded is > > eating keypresses, and the addition of a2 brings things back in order, > > for whatever reason. > > So what shall we do from here? I'm on it. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 22:27:57 +0200, a ecrit: > Upgrade: xbrlapi:amd64 (6.5-7, 6.6-2), That makes a huge difference, that's why I was asking for versions. In versions before 6.6-1, the xbrlapi package was trying to start brltty with a ba driver and an a2 driver, only to fail loading the a2 driver. So possibly the presence of brltty with only the ba driver loaded is eating keypresses, and the addition of a2 brings things back in order, for whatever reason. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 22:02:48 +0200, a ecrit: > Samuel Thibault (2023/09/04 21:28 +0200): > > Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: > > > Samuel Thibault (2023/09/04 21:01 +0200): > > > > So the behavior you expect is not actually implemented by Orca, it's the > > > > a2 screen driver that takes precedence in the text fields > > > > > > Well I am unsure about what you mean by text field here because, for the > > > little of GUI I am using (Firefox essentially), I have observed this > > > behaviour or not being able to use braille window navigation and routing > > > keys in a very constant way. Is any place in a web page really a > > > text-filed? > > > > Yes. Or more precisely: they all expose a text interface, even if they > > don't have a text role. Since apparently orca doesn't capture routing > > key events, these events fall back to being exposed to the a2 driver, > > which gives it to brltty, which uses a2 to read the widget content, and > > perform the cursor routing. > > Are you sure Orca does not deal with routing keys? I don't mean it's not implemented. I mean in the tests one can make, Orca doesn't happen to be doing anything with them. For *whatever* reason that might lie between the actual braille device and Orca. > Isn't this something that is working for years now? I have no idea about that, as I don't actually use Orca. > Unless there is a regression that happened in Orca and has somehow > been masked? Or in whatever is between the device and Orca. > Even theprecedence mechanism is not that old, probably newer than a2 > and thus even if a2 is there for a long time it's not such a long time > it cantake precedence over Orca when there are widgets they both know > how to render, right? Without actually taking the time to actually *inspect* what is happening, I'll just stop making any more guesses, it's a loss of time from all of us. > > > Also, if the a2 screen driver "just" takes precedence, shouldn't things > > > still work when it's not there? > > > > If Orca was capturing routing key events, yes. It appears that doesn't > > happen. > > That's a real surprise to me. Yes, but that's a fact: in my test it doesn't print any log upon routing key press. > > In the test I made with Roberto's case, it really was brltty's way of > > pressing arrows to simulate routing, that Orca doesn't implement > > anyway. > > In which context (applicaiton, widget) did you test? Routing key in pluma. > Intuitively, I'd have assumed that indeed orca is not simulating arrow > key presses as brltty does but that it rather implements the routing by > simulaitng moves of the mouse ppointer, and mouse clicks. > > In particular, I was under the impression that, in fFirefox, when I am > "clicking" on a link with the cursor routing keys, it's really like if I > was doing a mouse click. Ok, but what I saw was definitely brltty's routing, for whatever reason that might happen to be. > > But again, which version of brltty are you using? > > 6.6-2 So when brltty-x11 is not installed, you do not have a second brltty running, right? Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Roberto Burceni, le lun. 04 sept. 2023 21:39:07 +0200, a ecrit: > Ok but at this point which is the exactly the main function of brltty-x11? Providing a brltty-like experience wherever it can on the graphical desktop. Yes that's not very precise, because the details are dense. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: > Samuel Thibault (2023/09/04 21:01 +0200): > > So the behavior you expect is not actually implemented by Orca, it's the > > a2 screen driver that takes precedence in the text fields > > Well I am unsure about what you mean by text field here because, for the > little of GUI I am using (Firefox essentially), I have observed this > behaviour or not being able to use braille window navigation and routing > keys in a very constant way. Is any place in a web page really a > text-filed? Yes. Or more precisely: they all expose a text interface, even if they don't have a text role. Since apparently orca doesn't capture routing key events, these events fall back to being exposed to the a2 driver, which gives it to brltty, which uses a2 to read the widget content, and perform the cursor routing. > Also, if the a2 screen driver "just" takes precedence, shouldn't things > still work when it's not there? If Orca was capturing routing key events, yes. It appears that doesn't happen. In the test I made with Roberto's case, it really was brltty's way of pressing arrows to simulate routing, that Orca doesn't implement anyway. > > knows it brings better support in that case (the cursor routing you get > > is achieved by the brltty core itself, not the a2 driver which is only > > the "messenger"). > > But that is not what is supposed to happen when you click (use cursor > routing keys) on links in Firefox, right? Ah, that part seems odd however, indeed. But again, which version of brltty are you using? > > So it's not really Orca that "depends" on brltty-x11, it's just that > > brltty-x11 is an interesting complement to Orca, to improve screen > > reading. > > I don't think it's fair to put things this way frankly. Currently, you > simply can't read the screen in braille without brltty-x11... If that is so, it's a bug that needs a fix in Orca, and not just make people install brltty-x11 as a workaround that we don't even understand how it happens to work. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Roberto Burceni, le lun. 04 sept. 2023 21:12:44 +0200, a ecrit: > When I am in a browser and navitate with pan key, when I encounter an > unordered or ordered list, the braille display stay on the first item and do > not go on te following. > > To go to the next item I have to press down arrow key. > > Have you an idea about this behaviour? AIUI that'd have to be implemented in Orca. xbrlapi and brltty-x11 don't actually know about graphical items etc, they only provide some support within a given widget. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Ok, I see. So the behavior you expect is not actually implemented by Orca, it's the a2 screen driver that takes precedence in the text fields because it knows it brings better support in that case (the cursor routing you get is achieved by the brltty core itself, not the a2 driver which is only the "messenger"). So it's not really Orca that "depends" on brltty-x11, it's just that brltty-x11 is an interesting complement to Orca, to improve screen reading. That being said, perhaps the orca package should still recommend brltty-x11, the same way it recommends xbrlapi which also improves it. We however need to be very cautious because installing brltty-x11 installs brltty, which enables usb-serial drivers which hurt ftdi serial adapters users. I'll see how to arrange that. Samuel Roberto Burceni, le lun. 04 sept. 2023 20:43:17 +0200, a ecrit: > I'm using brltty 6.5 which is in ubuntu 23.04. But I discovered this problem > also in debian buster and bullseye with brltty 6.3. > > > Roberto Burceni > > Il 04/09/23 19:01, Samuel Thibault ha scritto: > > Roberto Burceni, le lun. 04 sept. 2023 18:51:50 +0200, a ecrit: > > > I confirm that without brltty-x11 you can not navigate nor use cursor > > > routing. > > Just to make sure: which version of brltty is this? There was a bug > > concerning keys in brltty 6.6, and a2 running might have a side effect. > > > > Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Alexander Epaneshnikov, le lun. 04 sept. 2023 00:08:42 +0300, a ecrit: > in order to return this fix, where the correction of the diff algorithm > should occur in libvte or in orca? In vte. Diff algorithms should be done as early as possible to avoid overflowing the rest. Samuel
Re: lesson learned
Jude DaShiell, le mer. 23 août 2023 18:03:17 -0400, a ecrit: > All I can tell you on that score was when I booted the machine I never > heard the grub beep. So it wasn't booting at all, thus not an accessibility issue, but an uefi/grub/lvm issue. Samuel
Re: lesson learned
Hello, Jude DaShiell, le mar. 22 août 2023 21:00:14 -0400, a ecrit: > I got that system installed fine, but once booted never got > a screen reader to come up and speak. But was it booting at all? If not, this is not an accessibility issue (I don't see how it could), and should be reported to debian-b...@lists.debian.org (or better, as a bug report). Samuel
Re: Choppy speech fixed when updating from bullseye to bookworm
Sukil Etxenike arizaleta, le dim. 13 août 2023 09:59:19 +0200, a ecrit: > > El 13/08/2023 a las 0:37, Samuel Thibault escribió: > > Samuel Thibault, le dim. 13 août 2023 00:35:37 +0200, a ecrit: > > > Subject says it all, it seems I only needed to update the apt sources to > > > a yet > > > not released version. The choppy speech is entirely gone. > > Was it the speech-dispatcher upgrade that fixed things? > > > No, I don't have Speech Dispatcher installed (maybe I didn't say I am using > Raspberry Pi OS Lite). You mean it's not the upstream Debian? > I don't know why it got fixed. Well, that's what we need to determine: what version of what software was not working before, and what version is now running fine. Otherwise I have simply no idea which version of the code you are running, and thus no way to have the slightest idea where to start. Samuel
Re: Choppy speech fixed when updating from bullseye to bookworm
Samuel Thibault, le dim. 13 août 2023 00:35:37 +0200, a ecrit: > Subject says it all, it seems I only needed to update the apt sources to a yet > not released version. The choppy speech is entirely gone. Was it the speech-dispatcher upgrade that fixed things? > Now the espeak-ng command fails to speak until I restart espeakup (I > have espeakup running on startup, and espeakup does speak), which > didn't happen before. "before" is a very imprecise thing. Without more precise details it's hard to answer. Samuel
Fwd: Choppy speech fixed when updating from bullseye to bookworm
From: Sukil Etxenike arizaleta via Pkg-a11y-devel Hi, Subject says it all, it seems I only needed to update the apt sources to a yet not released version. The choppy speech is entirely gone. Now the espeak-ng command fails to speak until I restart espeakup (I have espeakup running on startup, and espeakup does speak), which didn't happen before. Ideas to solve this (or pointers to where to ask this) would be appreciated. Thanks very much, Sukil
Re: [BRLTTY] 6.6 has been released.
Hello, I had uploaded it to debian unstable. It'll enter testing in a few days. Samuel
Re: Choppy speech when using espeak and espeakup on a Raspberry Pi
Hello, Sukil Etxenike arizaleta, le sam. 05 août 2023 19:10:17 +0200, a ecrit: > I am experiencing choppy speech when running espeakup and also when > running espeak on its own, but not when generating wave files and > playing them with aplay. I'd say this should be discussed with upstream espeak-ng, https://github.com/espeak-ng/espeak-ng/issues Samuel
Re: orca_45~alpha-1_source.changes ACCEPTED into experimental
Hello, I have uploaded the 45-alpha version of orca to experimental, for people to test and report issues to the orca mailing list. Samuel
Re: OT Re: Installing Voxin Eloquence Broke Speakup?
Hello, D.J.J. Ring, Jr., le jeu. 03 août 2023 11:56:48 -0400, a ecrit: > John Doe or whatever your real name is, It does not matter whether this is his real name or not, he has always been called John Doe here and there, and that is what does matter. > Go crawl into a hole, and hopefully that hole will be covered up with debris > and other things that seem naturally attracted to your type of personality and > we will not have to suffer through your misplaced anger and other personal > deficiencies. That kind of comment is not welcome on this list. Samuel
Re: newer version of libatspi for Bookworm?
Chevelle, le ven. 21 juil. 2023 10:51:53 -0400, a ecrit: > Is it possible libatspi2.48.3 or newer will make it to Bookworm or Bookworm > backports any time soon? bookworm-backports has opened only today, and not even announced officially, allow me the time to react :) Samuel
Re: Kernel Header Error
> Please install the linux-headers-5.10.0-23-686 package, Samuel
Re: ***UNCHECKED*** Re: Which softwares to install ?
LibreFaso, le mar. 27 juin 2023 18:42:22 +, a ecrit: > Anyway, I recently met one guy of Hypra and he told me that their layer of > accessibility (which constitutes the core of what they bring to their users) > is on debian.hypra.fr > I'd like to put it on the computer but I don't understand at all how to. > Should I just add this URL on the sources.list ? Yes. Samuel
Re: Cursor routing not longer working with kernel 6.3 on Debian testing
Hello, Christian Schoepplein, le ven. 23 juin 2023 16:37:45 +0200, a ecrit: > Is this a known issue with kernel 6.3? Unfortunately, yes: TIOCSTI poses security problems so it got disabled by default. I had warned at that time that it was needed for accessibility and proposed solutions, but didn't hear back anything. Now that the regression is there and users complain, perhaps they'll listen... Samuel
Re: Bookworm: BRLTTY constantly logs errors
Hello, Chevelle, le ven. 16 juin 2023 10:52:57 -0400, a ecrit: > I view the system log with 'journalctl -e' there are repeating errors. > Possibly it can't find yxa2.so. Oops. Are you actually using a braille device? If so, install the brlttyx11 package (and I wonder how it didn't get installed, how did you install/upgrade your system?). Otherwise you can remove the xbrlapi package, that'll avoid triggering brltty. Samuel
Re: How is unstable for dayly use?
Chime Hart, le mer. 14 juin 2023 18:42:40 -0700, a ecrit: > Hi Samuel: Is their an English-Language version of that item? Sorry, I didn't realize I pasted the french version. Of course there's the original english version: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.html#non-free-split Samuel
Re: How is unstable for dayly use?
Hello, Chime Hart, le mer. 14 juin 2023 15:43:52 -0700, a ecrit: > I get this message about BookWorm non-free changing its name. Release notes are there to be read. https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.fr.html#non-free-split Samuel
Re: How is unstable for dayly use?
Cleverson Casarin Uliana, le mer. 14 juin 2023 16:50:04 -0300, a ecrit: > that Orca in particular is still at version 43.1 in both Unstable and > Testing, while it's 44.1 in the experimental version. Since 44.1 was > released around one month ago, As a reminder, we have released Debian 12 only *last week-end*. Until then the rule was not to upload new stuff to testing/unstable, so Debian 12 could stay on stable grounds. Samuel
Re: to root or not to root
K0LNY, le jeu. 01 juin 2023 22:41:56 -0500, a ecrit: > I noticed that su - did not work for me, I had to do sudo su -. > I don't know if this was because I didn't install a root account. Yes, that's it. "su -" is meant to switch to another account by using its password. But if that other account doesn't have any password, you thus can't switch. sudo, however, wants your password, not root's password. Now, instead of "sudo su -", which is redundant (sudo already switches to root, no need for su), you can use "sudo -i" Samuel
Re: speakup configuration settings
K0LNY, le mar. 30 mai 2023 18:04:18 -0500, a ecrit: > But in my Debian 11.7, it seems that there is no speakupconf available. > Is that right? > Do I need to install it for it to be there? $ apt-file search bin/speakupconf speakup-tools: /usr/bin/speakupconf Samuel
Re: How to Install Basic Debian CLI System with Networking and screen reader
D.J.J. Ring, Jr., le dim. 28 mai 2023 22:33:44 -0400, a ecrit: > It should be an explicit choice to have a configured Debian Command Line > Interface (CLI) Text Mode. IIRC, I already explained here that this can be implemented as a "task" in the installer. It is thus a matter of somebody reporting a bug to the tasksel package to request for the addition of a "textual desktop" task, along with a list of packages that this task would install. Samuel
Re: Installing Open Media Vault
Hello, K0LNY, le lun. 22 mai 2023 16:29:45 -0500, a ecrit: > [1]https://www.openmediavault.org/ > But when I launch the ISO in VmWare, I get the computer beep, and the > soundcard > is checked in the attached devices, so I know the VM has access to audio, but > I > have tried pressing S and I have tried arrowing down 4 times and hitting enter > to get a speech install, but no speech. > Is it possible that OMV has no accessibility in it? It seems they have not enabled accessibility shortcuts in their boot menus at all. The speakup kernel modules and espeakup are not even available. Samuel
Re: a usible desktop
Hello, K0LNY_Glenn, le lun. 01 mai 2023 18:59:27 -0500, a ecrit: > I installed gnome-session-flashback > and that was a little better, but all the above issues persist. > I installed unity-session-desktop > or something like that, and it isn't much better. You'll probably want to install the MATE desktop, which is all using gtk3, not gtk4. I don't know if ubuntu can provide it, but at least Debian can. Samuel
Re: colors and fonts of debconf etc., a suitable xterm, vt
Samuel Wales, le sam. 08 avril 2023 14:15:42 -0700, a ecrit: > On 4/8/23, Samuel Thibault wrote: > > You can paste with shift-insert. > > this does not paste. It does in my rxvt. Note that it pastes the selection buffer, not the cut buffer. Samuel
Re: colors and fonts of debconf etc., a suitable xterm, vt
Samuel Wales, le ven. 07 avril 2023 21:27:05 -0700, a ecrit: > having trouble pasting into it as i cannot push a scroll wheel well. You can paste with shift-insert. > > setterm -foreground yellow > > > > that will show up as orange. > > where do i put this? .profile ends up having it work exactly once in > an echo satement after doing it. need precmd? You can probably put the content printed by the setterm command in your $PS1. > > You can tune font size with dpkg-reconfigure console-setup: use a > > Terminus font to get access to the 16x32 size. > > i had set that and it's still a bit small. but it is almost large enough. Larger fonts will be supported by the newer Linux kernel. Samuel
Re: colors and fonts of debconf etc., a suitable xterm, vt
Hello, Samuel Wales, le lun. 03 avril 2023 17:42:24 -0700, a ecrit: > in various places, such as debconf, there is a tui in debian that is > blue, grey, and red, with black text. > > e.g. dpkg-reconfigure sometimes uses it. i have a lot of trouble with > blue and some trouble with the brightness of the grey, but still want > contrast. can i change these colors to somethign that works better > for me? e.g. orange on black. Yes, you can tune colors with the NEWT_COLORS environment variable, e.g. export NEWT_COLORS='root=,black roottext=white,black window=,black textbox=white,black border=white,black button=white,black checkbox=white,black listbox=white,black' > urxvt -fn "xft:bitstream vera sans mono:pixelsize=32" \ > -background '#cd8000' > > this is color-backward from what i want Then use urxvt -fn "xft:bitstream vera sans mono:pixelsize=32" -foreground '#cd8000' > also the font is a bit too small for me. idk where find a number to > substitute for 32. You can pick up whatever number you like, since mono is a vector font. > also there is a grey border on the left that does not > go away with -bl and similar options. It is the scrollbar, you can turn it off with -sb or +sb > the accessibility issues include the white is much much too bright. > prefer orange on black or so. You can use setterm -foreground yellow that will show up as orange. > i can't always get legibly large fonts. You can tune font size with dpkg-reconfigure console-setup: use a Terminus font to get access to the 16x32 size. > i can't make the blinking cursor into a filled red block cursor > permanently. You can use echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink to avoid the blink, and tput cvvis to make it a block. You can stuff the former in /etc/rc.local and th latter in your .bash_profile Samuel
Re: espeakup stops speaking bookworm arm64
Hello, Frank Carmickle, le lun. 20 mars 2023 16:31:54 -0400, a ecrit: > I've reported this before, and I believe we had a fix for it. I don't remember what issue you refer to. Samuel
Re: debian installer accessibility for arm64
Frank Carmickle, le jeu. 09 mars 2023 13:24:10 -0500, a ecrit: > -device ich9-intel-hda -device hda-duplex Ok, I tried it and it worked here. Possibly there is something different in UTM vs qemu in Debian. Samuel
Re: debian installer accessibility for arm64
Frank Carmickle, le mer. 08 mars 2023 08:23:27 -0500, a ecrit: > > On Mar 7, 2023, at 19:18, Samuel Thibault wrote: > > Frank Carmickle, le mer. 15 févr. 2023 11:22:02 -0500, a ecrit: > >>> Samuel Thibault, le lun. 13 févr. 2023 22:41:16 +0100, a ecrit: > >>> https://people.debian.org/~sthibault/mini.iso > > > > I have updated the image above with the latest kernel from debian, which > > now includes sound drivers, could you download it again and try it? > > I have tried it. I have found that I couldn't, unlike the last image you > made, get it to come up talking. Ah? > Is it that you thought that speech wouldn't work? No, it's supposed to have the audio drivers, and espeakup, and thus have speech synthesis. > If so, you are correct, it does not. It seems as though the boot loader isn't > including the appropriate kernel options, but I can't tell because when I > press 's' it gives me the graphical installer. That's not expected. How did you actually drive the grub menu, precisely? How do you run your VM? I'm using qemu-system-aarch64 -cdrom mini.iso -m 1G -cpu max -machine type=virt -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -device intel-hda -device hda-output -serial stdio -device virtio-gpu-pci -device usb-ehci -device usb-kbd and that comes up talking after pressing s on the virtual USB keyboard or on the serial port (i.e. the graphical window or the terminal) > When I arrow down to the entry that should be "install with speech" I don't > get any output at all on the serial line. You mean after validating in a grub menu that does show up on the serial line? Please be *very* precise in your report, since I have no idea how things are happening on your side. > I've been trying to find the build instructions for the Debian Installer. Do > you know where I can find them? https://wiki.debian.org/DebianInstaller/Build but quite often there are rough edges. Samuel
Re: debian installer accessibility for arm64
Hello, Frank Carmickle, le mer. 15 févr. 2023 11:22:02 -0500, a ecrit: > On Feb 14, 2023, at 6:21 PM, Samuel Thibault wrote: > > Samuel Thibault, le lun. 13 févr. 2023 22:41:16 +0100, a ecrit: > >> Frank Carmickle, le dim. 12 févr. 2023 21:07:14 -0500, a ecrit: > >>> I've tried different emulated sound devices but the modules are not being > >>> loaded for any sound cards. > >> > >> Indeed, the sound drivers have not been included in the arm images. When > >> the issue with wxwidgets will be solved, I'll have a try at including > >> them. > > > > I have uploaded a test image, could you give it a try from: > > > > https://people.debian.org/~sthibault/mini.iso > > The first thing to note is that the image does not come up talking at all in > stock configuration. I have updated the image above with the latest kernel from debian, which now includes sound drivers, could you download it again and try it? Thanks, Samuel
Re: Debian Installer Bookworm Alpha 2 release
Hello, D.J.J. Ring, wrote: > I used the text installer to install speech, but no speech was heard > during installation. Usually that is because the firmware hasn't been > included. The old "non-free" images worked fine before, but I guess > not all the firmware that was in the "non-free" images has been put in > the Alpha 1 and Alpha 2 iso files. See the changelogs: Alpha 1 didn't have firmware (the vote wasn't even passed at the time), only Alpha 2 has them. To check about this and fix it, we'd need information from the working case: installation logs etc. from the bullseye firmware image. Also it would be useful to have the same information from the bullseye *non* firmware image, to see what is different between the two, which is making the card actually work. > What I am going to do is get one of the old firmware ISO's for Stable > Bullseye and install that because it worked, And then please report as mentioned above. > I have enclosed the files I thought would be helpful, They are showing that the drivers properly detected an hda intel card. They are not talking about missing firmware. That's why we'd need to compare with the bullseye case, to know what's happening differently. > I'm just frustrated at spending all this time to get the latest Debian > installed, Perhaps you can think of my frustration at not have the hardware that poses problem, and thus have to try to *divine* what could be going wrong in your case. > Probably it's just a small thing of firmware but lack of firmware > makes it very difficult to install Debian. And knowing what happens is very difficult without actually having the hardware at hand. That's why we need input to actually fix things. Samuel
