<div dir="ltr">Hello,<br><br>After reading about these two issues related to the
relativelly new polkit authorization / authentification support [1], [2]
I wanted to suggest that Arch linux brltty package should be modernized
to take advantage of new features and integrate better with the rest of
the system.<br>However in the process I've discovered even more issues and I think I'm getting lost in the chain of dependencies.<br><br>Currently
arch linux packages are built in chroot so only the dependencies listed
inside the PKGBUILD script are picked by the build system configuration
(that is autotools in brltty's case). There is an exception to this
though. Packages that are part of base and base-devel groups of packages
are all installed. So all base packages can be used as a runtime
dependencies and all base-devel packages can be used as a build time
dependencies. <br>Currently these are specified as runtime dependencies: libxaw gpm icu tcl bluez-libs espeak<br>And these as build time dependencies: at-spi2-core tcl speech-dispatcher cython<br><br>Configure is ran like this on arch linux<br> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \<br> --mandir=/usr/share/man \<br> --with-tables-directory=/usr/<wbr>share/brltty \<br> --with-screen-driver=lx \<br> --enable-gpm \<br> --disable-java-bindings \<br>Should
this be reconsidered? I assume linux driver is specific to linux and
there are drivers for other platforms such as Android or Windows that
are not suitable for linux for example. Should we rather rely on auto
detection here? At-spi2 driver might be clashing with orca. Are there
cases where it's usefull? What about screen driver? When using linux
driver and running screen on a tty is the screen output accessible to
brltty or should both drivers be in use in such a case? Or is the screen
screen driver only suitable when running on a mac as indicated by many
of the email list discussions?<br><br>I have run ./configure to see
which packages it checks for so I can try to come up with clear
suggestions on what to add or change.<br><br>linuxdoc and doxygen sound
to me as they would suit well as build time dependencies for building
the documentation. Have you a recommendation for me whether docs built
with these two packages should be included as a part of the binary
package? I guess doxygen docs are developer documentation for the API's
and linuxdoc is the user documentation. Is this correct?<br><br>Polkit
is not currently being used on Arch linux and because of the two already
mentioned issues that prompted me to look into this, we can say we
definatelly would like to get it added as a runtime dependency. Now a
related question: I am currently running arch brltty package with no
polkit support compiled in. When connecting to brlapi in python, I'm
getting this exception:<br>>>> import brlapi<br>>>> ba=brlapi.Connection()<br>Traceback (most recent call last):<br> File "<stdin>", line 1, in <module><br> File "brlapi.pyx", line 304, in brlapi.Connection.__init__ (brlapi.auto.c:5039<br>)<br>brlapi.ConnectionError: couldn't connect to b':0' with key b'polkit+keyfile:/etc<br>/brlapi.key': b'connect: No such file or directory'<br>(brlerrno 11, libcerrno 2, gaierrno 0)<br>Is BRLTTY really running?<br>I
know brlapi server is not running as I have no braille display
connected and since brltty 3.5 brlapi server is not started in such a
case. However by reading that output it's obvious polkit method is
attempted at the brlapi client side. Is this correct because in theory
we might like to connect to remote brlapi with polkit support in place
or is this assumption not applicable as polkit is only used locally?
According to the issue mentioned in [2] it looks to me as the arch linux
package has broken configuration as connection to brlapi will never get
authorized unless user explicitly turns on the brlapi api-parameter in
the config file. Is this correct and how to best avoid issues like this
for novice users?<br>I have tried to uncomment the key api-parameter in
my /etc/brltty.conf, I've also uncommented driver vr to try brltty
without a real braille display but I can't get the brlapi connection to
work. Can you give me a hint here on how to properly test this without a
physical braille display? Is virtual braille driver enough or I would
need tty driver or x driver? I would like to know that for my-self and I
will need it to know so I can write clear reproduce instructions for
the arch linux bugtracker.<br><br>ncurses this would perhaps be nice to
have as a runtime dependency. I can't really explain it so I would like
to hear some supporting arguments. I guess it's used for better
navigation in ncurses powered UI onatext console. Am I guessing right?
Or should this be an optional dependency meaning that it should be
installed during the build process and then optionally installed during
the runtime? Or there are no runtime checks like that?<br>Additionally
there is a possible problem related to the ncurses package as provided
in Arch linux. Recently (about two weeks ago) ncurses on arch linux has
got these two ./configure flags enabled: --with-termlib=tinfo
--with-ticlib=tic<br>When ncurses is built like this, brltty-ttb linking fails with the error:<br>/usr/bin/ld: brltty-ttb.o: undefined reference to symbol 'keypad'<br>/usr/lib/libtinfo.so.6: error adding symbols: DSO missing from command line<br>collect2: error: ld returned 1 exit status<br>See
the line 2167 of the file Programs/brltty-ttb.c. I would say we
*should* be checking for this symbol when running ./configure and
disable ncurses support accordingly. Or what can you suggest instead?<br><br>x11
libraries and extensions: Currently arch linux package only builds
against libxaw. brltty configure script is also checking for libx11,
libxtst and libxt. For xbrlapi and at-spi2 screen driver these are not
needed I guess. Are these needed for testing braille drivers only?<br>How
does the xbrlapi xsession integration work here i.e. is this session
agnostic meaning we can run it with whatever desktop including gnome,
kde, mate or even window managers or does this only make sense when
at-spi is running? How the xbrlapi binary gets inwoked and is it running
in the background?<br><br>sys/modem.h machine/speaker.h I can't find these. are these kernel dependent?<br><br>linux-api-headers should be added to the build time dependencies I guess.<br><br>sdkddkver.h is windows specific so add a note to my self that I shouldn't check it again.<br><br>Systemd
is included in arch linux however pkg-config --exists libsystemd
returns 0. It's better to use PKG_CHECK_MODULES instead. I've found an
example we can get some inspiration from [3]. This should be tweaked at
the brltty side of things. Alternativelly can I somehow enable systemd
units and udev rules generation and installation even if this check
fails?<br>Btw it's awesome brltty has such an extensive systemd / udev
integration. Distros are not picking that though. As arch linux does not
yet make use out of that partially because brltty is having not optimal
systemd detection but also because no one from arch linux has read
brltty changelog and its extensive documentation.<br>Systemd and other
dependent packages tend to put their socket files on a tmpfs mounted at
/run on Arch linux. When I'll change the api-socket-patch from
/var/lib/BrlAPI to let's say /run/BrlAPI . Will the clients using brlapi
be able to locate it or this is only used within this package?<br>What
about writable directory /var/run/brltty . Are the files written there
supposed to survive a reboot? How does that compare with /var/lib/brltty
as this is something I do also have on my system.<br><br>alsa-lib
should be added to runtime dependencies or is there a way to make it
optional i.e. can brltty handle it gracefully if I'll build it with
libasound present and then I'll remove it? What we might be missing if
libasound support is not compiled in?<br><br>What about libbraille it appears it's web page is down. Most likelly I won't be able to include that. Is it widely used?<br><br>dbus:
Is it used in conjunction with at-spi2-core? Or does it make sense to
build with dbus even if at-spi2-core is not available?<br><br>TTS
drivers. espeak is now runtime dependency, speech-dispatcher is optional
dependency. I would say festival and flite should be added as a build
time dependencies and then as an optional dependencies.<br><br>What is cspi support?<br><br>Script
Program/brltty-genkey is not installed. Should it be and can it be done
via included MakeFile? Are there more such scripts that might be
usefull?<br>We do have an install script which creates a file
/etc/brlapi.key. I am just wondering whether we should not use what
brltty provides instead of coming up with our own although in this
particular case this change is just cosmetic.<br><br>Is there a way to
use braille keyboard which is part of a braille display for typing? [4]
If brltty can do it it's very likelly I haven't yet understood how to
configure it. Can you please give me a hint on this too? Or this is what
the X11 extensions are usefull for?<br><br>Are there more hints you can give to me please?<br><br>I
apologize for a lot of questions like this however I believe we can get
this to rock! Imagine how cool it might be to just plugin your braille
display and the system will be able to recognize it to activate brltty.
My only problem is that I have no braille display it's why I am having a
lot of dumb questions. But still if possible I would like to do
something usefull.<br><br>Thanks and greetings<br><br>Peter</div>