Dick: Could you please write a patch for the current init script to warn about the old variables being used in the conf.d file? I am talking about things like ${RFCOMM_ENABLE}. The init script could also check if the matching services are set to Autostart=true in /etc/bluetooth/*.service.
Created attachment 120806 [details] check_bluetooth.sh Petteri please review; I think we should add some helper scripts for rfcomm, hid and pand. The new services can/ should only be configured using the DBUS interface.
(In reply to comment #1) > Created an attachment (id=120806) [edit] > check_bluetooth.sh > > Petteri please review; I think we should add some helper scripts for rfcomm, > hid and pand. The new services can/ should only be configured using the DBUS > interface. > if [ "$(eval echo \${${CONF}})" ] what's wrong with [ "${CONF}" ] ? if [ -x /etc/init.d/hidd ] ; then ewarn "hidd is not started by default via udev so" \ "please add it to the required runlevels" ewarn "using rc-update <runlevel> add hidd." This needs to say to remove ${HIDD_ENABLE} from conf.d to remove this warning Same applies to all the other variables. if [ "${PAND_ENABLE}" ] ; then if grep -q "^Autostart=false" /etc/bluetooth/serial.service then s/serial/network/ probably PAND and RFCOMM should share code About the helper scripts please take a look at what's here: http://websvn.kde.org/branches/work/kdebluetooth-dbus-integration/
Created attachment 120819 [details] check_bluetooth.sh Thanks for the feedback, I've updated the function. The eval is required to get the value of a variable variable. Consider: YKSI=1 ONE=YKSI $ echo ${YKSI} 1 $ echo ${ONE} YKSI $ eval echo \$${ONE} 1 The KDE works seem promising! What do you suggest? Depend on kdebluetooth? Maybe we can ask upstream to include some simple python / shell dbus scripts.
(In reply to comment #3) > > The KDE works seem promising! What do you suggest? Depend on kdebluetooth? > Maybe we can ask upstream to include some simple python / shell dbus scripts. > Not really on option to depend on it but the upstream maintainer was saying that he would do a release some time soon so we could then package that stuff.
(In reply to comment #3) This has always seemed an odd (and poor) way to recurse. TWO=1 YKSI=TWO ONE=YKSI $ eval echo \$${ONE} TWO So, playing the devil's advocate - does this really help? Is this just known as a variable variable variable then? What about the variable variable variable variable ... ?
bluez-utils-3 was removed from portage, so we can close this bug.
(In reply to comment #6) > bluez-utils-3 was removed from portage, so we can close this bug. > Ok. Thanks.
