[BRLTTY] Packaging questions

[Peter Vágner]

Hello,

After looking around and rereading brltty docs I do have some answers on my
own.
Kyle and Kelly what do you think about this?
I think talking arch will be affected too.



2017-10-25 17:23 GMT+02:00 Peter Vágner <pvdeejay at gmail.com>:

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

> 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?
>
All the dependencies should be treated like build time dependencies and
split packages depending on the external packages should be produced. It's
a similar package layout like brltty rpm packages found on the brltty
download page. It's a similar concept like pulseaudio is build for arch
linux. Gpm and ncurses should be added as gpm is so small it won't even
affect brltty-minimal too much which I guess may not be needed when split
packages will be introduced. Ncurses is available even on talking arch thus
very likelly also on each installed system. Linux braille driver should
remain built in with at-spi2 and screen drivers built as loadable modules
and seperated out into split packages.

> linuxdoc and doxygen sound to me as they would suit well as build time
>
> dependencies for building the documentation.
>
man pages will be installed with the brltty package and I suggest to split
doxygen and linuxdoc docs into brltty-doc package.

> 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.
>
I suggest to end up splitting this including relevant parts into
brltty-brlapi package.

> 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:
>
snip

> 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)
>
> This is already fixed for upcoming brltty version:
https://github.com/brltty/brltty/commit/7b688681f5868416d0b6b9899fbd0d2ba213477d
Perhaps it would be even nicer to improve it further so the polkit rules
file won't be installed if polkit support is not activated or polkit has
not been found. As in such a case that file is not needed I assume.

> Can you give me a
> hint here on how to properly test this without a physical braille display?
>
> Didier answered that for me and I have added these to my /etc/brltty.conf:
braille-driver    tt    # TTY
braille-device /dev/tty12

> 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
>
Ncurses is for making menus and stuff. I suggest to add it.

> ?
> 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?
>
> This is now addressed at the arch linux packaging side of things.
https://bugs.archlinux.org/task/56000#comment162794 However perhaps brltty
configure script might be enhanced to use pkg-config even for ncurses to
avoid breaking with such a ncurses build configurations elsewhere.

> 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?
>
Yes these are for X brltty driver. I'm suggesting to split it out as
described at the top of this message.

> 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?
>
> I don't know more about this yet. Perhaps a desktop entry put into
/etc/xdg/autostart would be usefull here? This is also usefull when we wish
to use braille device keyboard to type in within X.

> 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?
>
If nothing else I can change to their directory and run make install. I
will be using this technique for split packages where possible.

> 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.
>
> /var/lib/brltty is perhaps the default writeable folder. That has been
created by brltty on my system as it's not a part of any package. I still
don't know when brltty writes something in there however I will leave it as
is.
I suggest to change socket files location to to tmpfs mount the way other
arch packages are doing.

> 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?
>
> This is usefull for generating warning beeps and tunes when pc speaker
beeps are not possible. I would like this to be included as on an installed
system blind people  usually use sound unless there is no soundcard. I will
have to check how it works or fails on a system where there is no sound
card present.

> 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?
>
> Perhaps X braille driver I need to check more throughly as I haven't been
able to find this in the docs.

> 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.
>
> Split packages as for all the optional features.

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

> Or this is what the X11 extensions are usefull for?
>
> It appears these are not required for this as xbrlapi builds fine without
them.

> Thanks and greetings
>
> Peter
>
> Links:
> [1]:
> http://brltty.mielke.narkive.com/nWBtM3ui/problem-with-brltty-and-polkit
> [2]: https://mail.gnome.org/archives/orca-list/2017-October/msg00313.html
> [3]:
> https://github.com/xenserver/xen-4.5/commit/e6c3d371d475a10d2ebe9351472a2e
> c261023d72
> [4]: https://mail.gnome.org/archives/orca-list/2017-October/msg00310.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brltty.com/pipermail/brltty/attachments/20171027/078c2376/attachment.html>