kbluetooth4 for slackware 13-current
 

Here's a little guide and the slackbuilds for kbluetooth4 and its dependents.

First you are going to have to remove the old bluez-libs and bluez-utils packages. Bluez have merged both these packages into one.

All SlackBuilds have been optimized for x86_64. Change to suit your needs...

UPDATE!!!:
All SlackBuilds have now been fixed. Sorry me rushing things again lol :D
Fixed doinst.sh and SlackBuild in bluez to copy all the configuration files to /etc/bluetooth.
Added libusb-1* udev was not able to start the bluetooth daemon with the old legacy package.

Click here to download the packages.

Please build and install libusb and openobex before trying to compile the other packages.

PS:

You may want to make a symlink to the daemon startup scripts as if you have a internal bluetooth adapter it will initialize before the udev daemon and the bluetooth daemon will fail to load. Alternatively just start the bluetooth daemon from terminal.


Screenshot ..

kdebluetooth4 AFAIK needs updated bluez packages as well as obex-data-server (not yet in Slackware)

Everything is included in the first post. If you would like to try it out let me know how you get on. Cheers

Thanks for the above... This is still something in my 'todo' 'totry' list :)

But why not this app: http://kde-apps.org/content/show.php...content=112110

Not sure, but kdebluetooth seems down for a while. and this looks like a renewed project...

Hey dolphin77,

The link you provided is kbluetooth :D Just noticed there is a newer version, I'll update the package TY :D

I just noticed you are talking about kbluetooth, not kdebluetooth http://kde-apps.org/content/show.php...?content=84761

Hey again sahko. Yes I was talking about kbluetooth sorry I got confused because of the two being so similar.

Its all a bit confusing because there's kdebluetooth, kbluetooth and kbluetooth4 over on gitorious :/

Still both need the bluez-4* and obex packages.

drgr33n:

I mailed you about this. All things considered, not bad at all. I've got a "works for me" bluez4 stack (with blueman, a gtk app) up and running here, so I was curious as to any differences in your stuff and mine. Aside from style issues and a few minor nits here and there, we pretty much arrived to the same place from different directions, and that's a good sign :-)

I don't think it's necessary to have bluetoothd start at boot any more (so no need for rc.bluetooth), but I addressed that in the email, so we can continue this conversation there - I just wanted to offer some public kudos first :-)

Thanks for the scripts!

However, when I run kbluetooth4, I get errors like:
I don't get an icon in the task bar unless I run rc.bluetooth and in that case the icon is just jumbled pixels. No bluetooth devices are ever detected.

I get that same thing here with kbluetooth; that's why I use blueman :-)

I'm not *sure* about this, but *maybe* rebuilding kde with bluez4 installed will fix that. I've had more important things on my TODO list, so I haven't had a chance to find out...

Yikes! No thanks... Do you have a SlackBuild available for blueman?

Good job!

I have tried to get kbluetooth working before but never succeded. Hopefully it will work with your stuff.

/Magnus

rlworkman:

Why not publish working solution (I understood, it is bluez4 + gtk app blueman) on slackbuilds.org?

best regards,
Vladimir

EDIT: oops, you already posted while I was typing. Thank you.

@ rworkman,

EDIT: Sorry rworkman I found your email in my spam folder :( I've mailed you back.

lol we were thinking down the same lines on rc.bluetooth too :D I wasn't sure if it was necessary to add rc.bluetooth to start the daemon at startup ?. I left it as a matter of convenience and lack of testing ;)

@ everyone else

As for the error's I don't know if I will carry on with kbluetooth or also go down the blueman route?. kbluetooth seemed fine on my system but as I'm testing I'm finding more than a few issues as its far from a finished project.

Cheers,

Zarren

in obexfs.SlackBuilds should be :
/sbin/makepkg -l y -c n $TMP/$PRGNAM-$VERSION-$ARCH-$BUILD.txz
instead of
/sbin/makepkg -l y -c n $TMP/$NAME-$VERSION-$ARCH-$BUILD.txz}

in openobex.SlackBuilds should be
tar xvf $CWD/${PKGNAM}-$VERSION.tar.gz || exit 1
instead of
tar xvf $CWD/${PKGNAM}-$VERSION.tar.bz2 || exit 1


are there any additional dependencies? What is the correct build/install order?

obexftp and obex-data-server doesn't build for me. It dies with some errors.

Ok dolphin77 I'm looking into this now. What error's are you getting ??

sh obex-data-server.SlackBuild

sh obexftp.SlackBuild:

Blueman is certainly more mature, and in the long run is a better choice as it will work in the other WMs (like XFCE) without having to install KDE.

I have been running BlueZ 4.x on Slackware 13 for awhile now, and all that is really required is a competent front-end (which simply wasn't available for the stable Slackware 13 release).

I am surprised to hear Blueman is working, I have tried unsuccessfully to get it to run on Slackware 13 a few times now, it has always failed with obscure errors that the developers told me was due to the recent builds requiring a newer GTK2 release.

Hey again guys,

Everything's been fixed now WOOP WOOP :D Also kbluetooth has been updated to its git version. Should solve the dodgy icon.

As for blueman, more packages MS3FGX was right gtk+2 need updating plus libnotify, notification-daemon and notify-python are needed. I'm busy for a few days I'l take a look then.

EDIT: I've got blueman working by upgrading glib, gtk+2 and pango to their latest versions. Also found a handy script that adds browsing support to blueman via dolphin. I'll add all this in the next few days.

@ dolphin77

Do you have ruby installed and are you installing the new openobex package before building obex-data-server ?

Cheers,

Zarren

To anyone interested,

I finally got this to build

order of events:

remove libusb-0.1.12
build and install in this order:
libusb-1.0.6
libusb-compat-0.1.3
openobex-1.5
bluez-4.58
obex-data-server-0.4.5
obexd-0.19
obexftp-0.23
obexfs-0.12
kbluetooth-git

fixed errors in slackbuilds that dolphin77 points out

I downloaded the libusb-compat package from the libusb.org site, removed the stock libusb, and installed libusb-1.0.6 and libusb-compat-0.1.3 (do not know if this was strictly necessary, but it is working well for me, ymmv).

despite upgrading ruby, obexftp would not build without adding --disable-ruby in the configure options

tobyl

Re libusb updates, I've got those queued up here for -current sooner or later, but they weren't necessary for building kbluetooth - was there some other reason you wanted those?

Re obexftp, I experienced the same here with ruby - I just disabled it and made a note about it. If anyone cares, they'll figure out how to make it work. :-)

I'm sorry I didn't get any error's while building obexftp ? Maybe I have something else installed that is necessary to build obexftp with ruby support. Maybe rails ?? I'll look into this later this evening.

libusb is not needed for building kbluetooth, the reason it was added to the packages is because udev would not start the bluetooth daemon without upgrading libusb (on my machine) ??

Robby,
I upgraded libusb simply because I couldn't get kbluetooth to work, and was trying all the options. I am guilty of trying several changes at once - hence I did not know for certain whether the libusb changes contributed to my eventual success.
When I saw libusb-1 in drgr33n's package list, I assumed incorrectly that a) it was required, and b) that it replaced libusb-0.1. So I removed libusb-0.1 and installed libusb-1.

Subsequent attempts at building one of the other packages errored on libusb-0.1 not being present, so I installed the compat package.

Silly really, but it was caused by the fact that a lot of packages have next to useless INSTALL and README files these days, and the dependencies are often not listed.

tobyl

Interesting; kbluetooth still doesn't work for me, and I've got all of the above (and then some) done here locally. We're eventually going to get all or most or at least some of this out into the -current tree, so maybe some more eyes looking at it will figure out the missing bits...

When all said and done I'm still sticking to kbluetooth4 is still quite abit buggy. it requires a solid update amongst other things.

After trialing kbluetooth and blueman I think blueman is a much better option ! :D

Only a gray icon and no adapter found...
 

Hi guys,

First, thanks for the tutorial. I was able to compile and install everything, but when I start the kbluetooth4 I only got a gray tray icon and no options enabled in the menu...

I tried to run the kbluetooth4-devicemanager (I don't know if this makes sense for a test ;)), but I only got a "No Bluetooth Adapter found!" message.

My adapter is listed as:
- Bluetooth Dongle (HCI mode)
- Cambridge Silicon Radio, Ltd

Does anybody have an idea of what I need to do to have this adapter working, or how/where can I get more information about what may be preventing the adapter for being found by kdebluetooth4?

Thanks a lot!
Jean

Hi JeanSimeoni,

Not sure if this is your problem, but it sounds like

you need to run /usr/sbin/bluetoothd (as root)

also try removing your adapter and plugging it in again, or running

udevadm trigger

which will cause udev to scan your system, as I think udev misses the usb dongle on bootup

I am assuming that you have not got /etc/rc.d/rc.bluetooth executable (its somewhat outdated for our purposes)

tobyl

I'm not sure what's going on with the adapters not triggering "bluetoothd --udev" at system startup. I asked Marcel (the lead dev) in #bluez on freenode if he'd had any other reports of that, and he said no, so this is a bit bothersome. I don't think udev is the problem, because I'm fairly certain that you guys are not running the same udev that I am :) I'm on 149 here locally, and I suspect that most (all?) of you are still on 141 from 13.0. I seem to recall that the problem did NOT exist in bluez-4.56, but I haven't had a chance yet to downgrade and test that. Assuming it does start properly there, then I've got a git checkout of bluez ready for bisecting :-)

The only other real problem that I've experienced is that one of the blueman components (related to the applet) that's started when a bluetooth adapter is hotplugged seems to occasionally go crazy and start doing massive disk I/O. Unfortunately, I've got too many other things on my plate right now to spend too much time troubleshooting that, and I don't want to report a bug to upstream blueman without more information...

I'm on it rworkman ;) stand by for more info !!

EDIT:

Hey guys,

@ JeanSimeoni

Are you using a usb device or is it built in ? If its built in hotplugging will not work for this device and you have to start the bluetooth services manually.


@ rworkman

It seems the I/O interference is down to blueman flooding udev ?? the trunk version of blueman seems to have solved this one ? Got a poker match to attend to ;).

Sorry I haven't been keeping up but i have had two exams in the last 3 weeks and things have been hectic. I'l try to get some more done over the weekend.

Muchos Gracias,

Zarren

Interesting; that means we just might need an rc.bluetooth after all. More investigation needed, I guess. On that note, I downgraded to 4.56 here, and bluetoothd still doesn't start at boot, so now I'm thinking that I probably am misremembering. I hate when I do that. :)

Maybe revision 206 from their bzr repo is the commit that addressed this.

No worries - I understand how that goes.

Hey guys,

I think I've got blueman and its dependents to a pretty stable state. More trials are needed I think, but so far so good. there are quite a lot of things needing updating though to get blueman running as it should.

I think we may still need rc.bluetooth for the moment as I think we may never get hotplugging working for internal bluetooth cards. maybe it will be fixed in a later version of bluez ?? I've tried bluez 4.56, *.58 and udev 141, 149 and still no difference.

I've been trying to get blueman to replicate the udev flood bug with the trunk version and so far so good, no out of the ordinary behavior. I will post everything that was needed tomorrow.

Aha! I stumbled across an Ubuntu forum post that points out what is now rather obvious.
bluetoothd needs dbus to be running, but guess what's not running during early boot? :-)

There are at least two ways to fix this:

1) Make an /etc/rc.d/rc.bluetooth script that contains this:
2) Start dbus earlier in boot.

It *still* might not be possible to start dbus early enough, but that's my preferred approach regardless - I'd like to start dbus early in boot so that wicd users can depend on the network being up earlier.

At this point, assuming the blueman disk thrashing issue is truly resolved (and it seems that it is), I'm happy with the state of these packages. Unless there's a way to use konqueror or dolphin to browse obex:// links, there's not going to be a solution to that problem (unless you know something I don't). Either way, we can perhaps patch blueman/Constants.py.in to change OBEX_BROWSE_AVAILABLE to False, or we can change DEF_BROWSE_COMMAND to something besides nautilus (e.g. konqueror).

Hey Robby,

I've just emailed you about the konqueror problem buddy. I think I have a solution that will work. As for starting dbus earlier I don't think this will be possible. I did have an idea it was down to this, I think I may of said in an earlier post ?? And I did try to get dbus to start early enough but was unsuccessful. (Although I didn't spend to much time on this)

Cheers,

Zarren

Received and replied - thanks :-)

You probably did, and I probably overlooked it. I had "blinders" on for far too long with this issue :/

As I said in the reply mail, I don't think we'll be able to start dbus early enough for this, but there are other reasons to start it as early as possible anyway, even though the bluetooth issue will be fixed in another way.

Bluetooth headset not working
 

I have been trying to get a BT headset to work for a couple of hours now. *pull hair*

It has been paired succesfully with blueman and below is some info about the headset.

Every time I try to use the headset I only get some static noise and a strange message in the log:

hci_scodata_packet: hci0 SCO packet for unknown connection handle 45

The bluetoothd is running with debug and displays the following:

I have done a *fair* amount of googling but have only found something about patching the kernel..

Any ideas?

TIA/Magnus