Hi Samuel, > > > > > > bluez-libs currently FTBFS on hurd-i386 and kfreebsd-* just because > > > > > > it > > > > > > uses a non-standard errno code EBADRQC. > > > > > > > > > > > > I'm not sure about the right way to go: should bluez-libs, for > > > > > > portability reasons, use another error code, or should the Hurd and > > > > > > BSD > > > > > > add this particular error code. > > > > > > > > > > I don't know either, do hurd and kfreebsd support bluetooth at all? > > > > > > > > The Hurd does not yet, but that's no reason (and I don't know about > > > > BSD). > > > > > > It looks like a good reason to me, bluez is the official linux stack, > > > other > > > kernels might use different bluetooth stacks. > > > However, I'm bringing this to bluez-devel to have more comments/opinions > > > on this > > > and how it should be fixed (or not). > > > > > > My best understanding is that EBADRQC is used in linux in a few places > > > ( http://lxr.u1i.net/ident?i=EBADRQC ). Given that bluez is > > > linux-specific I > > > might considering removing hurd and kfreebsd as architectures from > > > libbluetooth, > > > would be that a suitable solution? > > > > I dont't care what hurd or kfreebsd are doing. If you are not running a > > Linux kernel it makes no sense to have any BlueZ specific package. > > Ah, I thought that a bluetooth protocol, although needing an ioctl > interface with bluetooth devices, would be generic (and it seems to be: > it compiles fine...)
of course it compiles fine, because it is all simple C code. However without the Bluetooth subsystem of the Linux kernel it is totally useless. Regards Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
