[BRLTTY] Packaging questions

[Peter Vágner]

Hello,

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.
However in the process I've discovered even more issues and I think I'm
getting lost in the chain of dependencies.

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.
Currently these are specified as runtime dependencies: libxaw gpm icu tcl
bluez-libs espeak
And these as build time dependencies: at-spi2-core tcl speech-dispatcher
cython

Configure is ran like this on arch linux
  ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
    --mandir=/usr/share/man \
    --with-tables-directory=/usr/share/brltty \
    --with-screen-driver=lx \
    --enable-gpm \
    --disable-java-bindings \
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?

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.

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?

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:
>>> import brlapi
>>> ba=brlapi.Connection()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "brlapi.pyx", line 304, in brlapi.Connection.__init__
(brlapi.auto.c:5039
)
brlapi.ConnectionError: couldn't connect to b':0' with key
b'polkit+keyfile:/etc
/brlapi.key': b'connect: No such file or directory'
(brlerrno 11, libcerrno 2, gaierrno 0)
Is BRLTTY really running?
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?
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.

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?
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
When ncurses is built like this, brltty-ttb linking fails with the error:
/usr/bin/ld: brltty-ttb.o: undefined reference to symbol 'keypad'
/usr/lib/libtinfo.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
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?

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?
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?

sys/modem.h machine/speaker.h I can't find these. are these kernel
dependent?

linux-api-headers should be added to the build time dependencies I guess.

sdkddkver.h is windows specific so add a note to my self that I shouldn't
check it again.

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?
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.
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?
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.

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?

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?

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?

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.

What is cspi support?

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?
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.

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?

Are there more hints you can give to me please?

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.

Thanks and greetings

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brltty.com/pipermail/brltty/attachments/20171025/9dbc61e6/attachment.html>