Hi

Dave Mielke <[email protected]> writes:
 > [quoted lines by Aura Kelloniemi on 2020/08/23 at 01:21 +0300]
 > I think it's better to do this kind of testing using a text console so that 
 > you
 > don't have the added complexity of knowing which brltty instance Orca is
 > connecting to.

I don't use any graphical environments, except in special situations.

 > You don't need to install an experimental brltty in order to test it. 
 > Instead,
 > just build it and then run what you just built by using the run-brltty script
 > in the top-level of the source tree.

But aren't there two things to test?

First thing is whether BRLTTY runs correctly, if it is started as root, and it
changes the privileges it uses by itself. This can be tested by running it
from the build tree. This is a good thing to test, because there are many
people who do not (and don't want to) use systemd, so BRLTTY being
self-sufficient is great.

The other thing to test is whether the systemd configuration works. As far as
I understand, the [email protected] defines the User, Group and
AmbientCapabilities because systemd is capable for setting them for BRLTTY by
itself. This I cannot test by running from the build tree, unless I install
the systemd config files, which has nasty consequences on my system.

 > Could you please send me all of your systemd-related files so that I can 
 > have a
 > look at them?

I will send you the Arch package that I built and used to install the broken
BRLTTY. It can be extracted with GNU tar.

 > >I had brltty.path, [email protected], [email protected], udev rules, and sysusers 
 > >and
 > >tmpfiles configuration files. 

 > What's the path to your installed sysusers file for brltty?

/usr/lib/sysusers.d/brltty.conf

 > I'm guessing that you have /etc/brlapi.key, and that it's owned by the brlapi
 > group. That, by the way, is exactly hw I do it.

Yes. Attached in this message is the Arcj build script that I wrote and used
to build the BRLTTY package.

 > >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: 
 > >987(uucp)

 > This one is odd. Are your serial devices, e.g. ttyS0, owned by the uccp group
 > rather than by the dialout group? Maybe there are two (or more) "standards" 
 > for
 > serial device ownership.

They are owned by uucp and that seems to be what Arch udev rules do. Therefore
it would be nice if BRLTTY's install did not enforce creation of a dialout
group, because it being present on the system might make some other
application believe, that they should use this group (which does not have any
permissions anywhere).

 > >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: cannot create 
 > >directory: /run/brltty: Permission denied

 > This problem needs to be fixed. For now, maybe you should just manually 
 > create
 > the /run/brltty directory. The solution will probably be for [email protected] 
 > to
 > use ExecPre to create it.

Maybe using 'install -d -o brltty -g brltty -m0700 /var/run/brltty'. This does
not fail if the directory already exists, but fixes its permissions if needed.

 > >BRLTTY fails to open /dev/tty1 (Permission denied) 

 > I guess that's what "Lupa evätty" means.

Yes, sorry, I did not notice that when de-translating other messages.

 > >even though it manages to join the group tty (/dev/tty1 is owned by my user
 > >and has group tty).

 > What are its permissions? Tle whole ls -l output line would be interesting to
 > see. In any event, this shouldn't be an issue if brltty is running as root.

crw------- 1 secret_user_name tty 4, 1 Aug 22 21:37 /dev/tty1

 > >The only group missing is dialout, because I already removed the systemd 
 > >files
 > >shipped with brltty (to get it running as root).

 > That wouldn't remove brltty believing that it needs access to it.

No, of course, but it should not have consequences except for one error
message. Or if it does, it is another bug to be hunted.

 > >dialout should not be needed for screen access though.
 > It isn't - it's for serial device access. On your system, however, it seems
 > that the uucp group might be used for this.

I'm actually very amazed that BRLTTY is so smart that it dug this information
from the device node itself. Great work, I'd say.

 > That, however, may be why you aren't benefitting from the rule to fix the
 > /dev/uinput access problem.

At that point I still had all the rules, so it should not be that.

 > Well, brltty can. It does so by retrying, which can mean that it'll connect 
 > to
 > the device somewhat later than as soon as possible. That's why it depends on
 > that service - so that it'll start as soon as udev is ready.

The problem of systemd-udev-settle (according to a sourcw I found using a
well-known search engine) is that it blocks the system bootup process. Because
BRLTTY is wanted by sysinit.target and BRLTTY depends on systemd-udev-settle,
then sysinit.target cannot be reached before /dev is ready, which might slow
down the boot. I have BRLTTY now running without this dependency (it is only
scheduled to be run before sysinit.target) and it works fine.

I guess that BRLTTY should stop using this deprecated unit and just be
self-sufficient – i.e. be able to handle the situation where /dev is not
populated. It seems to be doing already very well.

-- 
Aura

# Maintainer: Aura Kelloniemi <[email protected]>

pkgname=brltty-aurum
pkgver=6.1.r442.g4be6f8cf1
pkgrel=1
pkgdesc="Braille display driver for Linux/Unix (development version)"
arch=('x86_64')
url="https://brltty.app";
license=('LGPL2.1')
depends=('alsa-lib' 'expat' 'icu' 'liblouis' 'pcre2' 'systemd')
makedepends=('autoconf' 'automake' 'at-spi2-core' 'bluez-libs' 'cython' 'dbus'
             'doxygen' 'espeak-ng' 'glib2' 'groff' 'libxaw' 'libxtst'
             'ncurses' 'linuxdoc-tools' 'pkg-config' 'polkit'
             'speech-dispatcher' 'xorgproto')
optdepends=('at-spi2-core: X11/GNOME Apps accessibility'
            'atk: ATK bridge for X11/GNOME accessibility'
            'bluez-libs: bluetooth support'
            'espeak-ng: espeak-ng driver'
            'libxaw: X11 support'
            'polkit: PolicyKit support'
            'python: Python support'
            'speech-dispatcher: speech-dispatcher driver')
conflicts=('brltty')
provides=('brltty')
backup=(etc/brltty.conf)
options=('!emptydirs')
install=brltty.install
source=(${pkgname}::'git+https://github.com/brltty/brltty.git'
        "brltty.install"
        "brltty.tmpfiles")

sha256sums=('SKIP'
            'd6d69f812b04934debe8865e7d35ac4e0000361b00eab7314e588a56be57c0ae'
            '393e2d4007e9da43d3a5756aafa473b83acde788b1a5f4f706526fc8c6003cd2')

pkgver() {
    cd "${srcdir}/${pkgname}"
    # cutting off 'BRLTTY.' prefix that presents in the git tag
    git describe --long | sed 's/^BRLTTY.//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

build() {
    cd "${srcdir}/${pkgname}"
    ./autogen --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
            --mandir=/usr/share/man \
            --with-tables-directory=/usr/share/brltty \
            --with-screen-driver=lx \
            --disable-gpm \
            --disable-tcl-bindings \
            --disable-java-bindings \
            --disable-lisp-bindings \
            --disable-ocaml-bindings \
            --without-espeak --without-theta --without-swift \
            --with-rgx-package=libpcre2-32 \
            --with-curses=ncursesw \
            --without-midi-package --without-fm-package \
            --disable-stripping

    # Fix ncursesw header include
    sed --in-place -e 's|^\(#include \)<ncursesw/ncurses\.h>|\1<ncurses.h>|' \
        Headers/get_curses.h

    # Reduce display update rate
    sed --in-place -e 's|^\(#define UPDATE_SCHEDULE_DELAY \)15|\1 50|' \
        Programs/parameters.h

    make 
    make -C "Documents/"
}

package() {
    cd "${srcdir}/${pkgname}"
    make INSTALL_ROOT="${pkgdir}" install
    install -vDm 644 "Documents/brltty.conf" -t "${pkgdir}/etc/"
    install -vDm 644 "../brltty.tmpfiles" \
        "${pkgdir}/usr/lib/tmpfiles.d/${pkgname}.conf"

    make -C "Autostart/Systemd/" INSTALL_ROOT="$pkgdir" install
    make -C "Autostart/Udev/" INSTALL_ROOT="$pkgdir" install
}
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: [email protected]
For general information, go to: http://brltty.app/mailman/listinfo/brltty

Reply via email to