Bug#376860: [Bluez-devel] Bug#376860: [Pkg-bluetooth-maintainers] Bug#376860: bluez-libs: FTBFS on hurd-i386 and kfreebsd-*

[Marcel Holtmann]

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