On Fri, Mar 28, 2008 at 1:42 PM, Stefan Lippers-Hollmann <[EMAIL PROTECTED]> wrote: > If you look at the history of this bug, it had be reassigned to linux-2.6 > in august 2007 (and re- reassigned to lirc ~2 weeks later after talking > to linux-2.6 maintainers).
Ah yes, I should have seen that. It looks like Julien believed that the problem was a _userspace_ application including bttv.h, not a kernel module depending on a header that isn't part of linux-headers for some reason. If the lirc userspace tools want to compile against bttv.h from the kernel, that's a separate issue with a separate solution. I still have the feeling that I'm missing something -- it seems like including a header in linux-headers, if there are Debian-packaged kernel modules that need it in order to build, is such a no-brainer that I must be misunderstanding what's going on :-/. That's true even if the headers are not part of any legitimately exported kernel API. I mean, the whole "breaking Linux headers out into a separate package so that kernel modules can compile against it even if they _think_ they need to compile against a previously-built kernel source tree" idea is a Debian-specific construct, with nothing to do with the upstream kernel, right? I just don't see any sense in which bttv.h should be considered "private" and not provided to a kernel module that wants to compile against it. Again, I must be missing something. > In the end this bug is totally unimportant as long as #471383 remains > unfixed, which prevents lirc_gpio from compiling at all with recent > kernels (2.6.23, 2.6.24). I agree with all of this and what follows completely -- it sounds like not compiling lirc_gpio at all might be a good way to kill two birds with one stone :-). If upstream isn't keeping it working with modern kernels, then I don't see much reason for it to hang around causing problems for the other modules in the Debian package. Cheers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
