Hi Lars,

Thanks for the bug report. I am not the brltty package maintainer, but I've done some drive-by work on the package and addressed at least one of the issues: it's going to be updated to 4.5 in Fedora 19.

The other two points remain unfixed though, I'm leaving it to the actual brltty maintainers:

 - Systemd unit script
 - Bluetooth support

This:

http://www.mielke.cc/brltty/doc/Manual-BRLTTY/English/BRLTTY-3.html

Makes me think enabling bluetooth isn't possible at this time.  I've played around with build options and nothing I do seems to generate a BT driver or link against bluez-libs.

Hi Jon

Thank you for working on the BRLTTY package for Fedora.

You wrote:

> This:
> 
> http://www.mielke.cc/brltty/doc/Manual-BRLTTY/English/BRLTTY-3.html
> 
> Makes me think enabling bluetooth isn't possible at this time.
> I've played around with build options and nothing I do seems to
> generate
> a BT driver or link against bluez-libs.

I asked the developer on the BRLTTY mailing list, and he replayed:

"You're trying to define a non-problem by assumptions. Brltty neither
creates a Bluetooth driver nor links against the bluez libraries. It
simply opens a Bluetooth socket and uses it."

Be aware that bluez-libs-devel must be available while building BRLTTY
to include bluetooth support. Please make a package, and I'll happily
test it.

Thanks and regards,
Lars

Ok, give 4.5-3 in rawhide a try.

There seems to be too many dependency packages to install, to get
brltty updated from Rawhide. Is it possible for you to provide a
package built for Fedora 18 (x86_64)?

Lars

http://fedorapeople.org/~limb/brltty/

Thank you. I can confirm that BRLTTY now works with bluetooth.

Could you also please provide a systemd unit startup script for
BRLTTY?

Thanks and regards,
Lars

Try 4.5-4 at the above URL.

It's not in rawhide yet, but I'll push it there and to f19 if it works for you.

When I last poked at brltty, I noticed that there was a systemd unit file in the Hotplug/ directory -- maybe it would be best to reuse that one?

-----

Also, what the hell is the %post script doing? Creating a bunch of device files, but we've long ago moved to udev/tmpfs for /dev, so they won't last over a reboot?

%post
devices="/dev/vcsa /dev/vcsa0 /dev/vcc/a"
install=true
for device in ${devices}
do
   if [ -c "${device}" ]
   then
      install=false
      break
   fi
done
if $install
then
   device="$(set -- ${devices} && echo "${1}")"
   mkdir -p "${device%/*}"
   mknod -m o= "${device}" c 7 128
   chmod 660 "${device}"
   chown root.tty "${device}"
fi
exit 0

I think I'll stick to the more basic one I made, unless it doesn't work, as it's more in line with what our guidelines recommend.

I think those %post bits can be dropped.

Lars, if the unit file works, I'll put up another iteration with the %post cleaned up, if you wouldn't mind testing that.

(In reply to comment #11)
> I think I'll stick to the more basic one I made, unless it doesn't work, as
> it's more in line with what our guidelines recommend.

Sure yeah, I've now looked at the files and I agree that your version is much nicer. However, please also submit your version upstream -- there's no reason to carry this downstream forever if we can get the upstream version fixed up.

Hi! Thank you - the startup script works. Even though, I would add
that BRLTTY is a service that we need up and running as early as
possible in the boot up sequence. That way, a braille user is given
the opportunity to follow the boot process and in case of failure,
take action to fix them.

When BRLTTY is started up, it searches periodically for the device(s)
specified in the config file, until one device is available. When
BRLTTY is enabled in systemd, I think it should start as early as
possible, and when the device, let's say it's a bluetooth device, will
come up as soon as the bluetooth stack is up and the connection is
possible. If the device is a serial device, it will certainly start
earlier, and that's all fine.

Yes, in a few days, I will test agin, sure.

Thanks and regards,
Lars

I can't find any later version than 4.5-4 on
<http://fedorapeople.org/~limb/brltty/>. Did you forget to put up a
test without the %post section, to test?

Lars

Less forgot than wanted to wait until the systemd bits were tested.

4.5-5 is now there, including systemd and the removed post bits, as well as the recently commited python3 changes that should be utterly orthagonal to what we're working on here.

Thank you very much for your work. The unit file works. However, as
mentioned in comment 13, if BRLTTY can be started earlier, it would be
nice. Also, when shutting down the system, if BRLTTY could be one of
the last services that terminates, it would be fine. Remember, BRLTTY
gives a blind person access to the screen content, and the screen
content is as important to him as to others. Anyway, the unit works.

I get some dependency problems when trying to install qemu on my
Fedora f18 system after I installed your build of BRLTTY, however,
this may work on f19, I don't know.

Thanks and regards,
Lars

Makes sense.  I certainly sympathize, and agree that it should be started sooner, but is there a reliably available .target that would be better?  I'll commit it as is for now, but am open to suggestions.

brltty-4.5-5.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/brltty-4.5-5.fc19

Thank you very much!

Lars

Package brltty-4.5-5.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing brltty-4.5-5.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8108/brltty-4.5-5.fc19
then log in and leave karma (feedback).

brltty-4.5-5.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.