SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've got udev from system-215 queued up, but it's unclear as to whether there's any real benefit to using 215 versus 208 or even some other version. It might be worth getting 218 when it releases, as that will be the first version to support the mouse database for libinput.
I didn't know about version 3.x being more compatible with BusyBox.
When I was debugging it, I don't recall feeling that it had anything to do with busybox -- more to do with some peculiarities of the installer and the more complex bunch of scripts that dhcpcd v6 had -- which I think are entirely unnecessary for the installer. Version 3 compiles still and it obtains an IP address, so it's fine.
busybox gets updated on ARM more often since for some reason it refuses to compile more readily than x86.
Very true. Speaking of which, isn't the installation disk software created in a similar style to how you create something similar to a base LFS system like CLFS-embedded with a specialized user or chroot jail, or created in the standard system? I don't think this has ever been really discussed much.
alienBOB updated it significantly for Slackware64 and the same script is used for all archs, with some wrap up scripts for the couple of ARM installer images.
Here are the changes in packaging against that of brltty-4.5 shipped in Slackware in /extra, beyond the version:
autogen is not run (not needed)
The script bp2cf that comes handy to customize the config file is installed in /usr/sbin. It comes from git because the one in the tarball doesn't work with the new config file format.
A file to manage the daemon is provided: /etc/rc.d/rc.brltty
A file doinst.sh is shipped that configure /etc/rc.d/rc.brltty in addition to /etc/brltty.conf and also inserts this in /etc/rc.S after udev has been initialized:
Code:
# Start brltty ASAP so that the user gather all further messages on the
# braille terminal
if [ -x /etc/rc.d/rc.brltty ];then
sleep 3
/etc/rc.d/rc.brltty start
fi
Rationale: this allows the blind user to get all further messages during startup, useful in case of failing file system check for instance.
udev rules are shipped in /lib/udev/rules.d/40-usb-brltty.rules. They allow to automatically start brltty with a proper driver as soon as a terminal connected via USB is plugged-in.
Pat needs to upgrade exiv2 first, before he grabs my KDE 4.14.3 sources.
Eric
That would be very helpful, as digiKam can't be built on -current (it does built, but segfault), since it will require exiv2-0.2.4 and KDE libkexiv2 rebuilt against it
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.