[Pkg-lirc-maint] Bug#436166: Bug#436166: Bug#436166: Progress notes
s.L-H at gmx.de
Fri Mar 28 18:34:48 UTC 2008
[sorry, I accidentally hit 'send' too early before completing this mail]
On Freitag, 28. März 2008, you wrote:
> On Fri, Mar 28, 2008 at 1:42 PM, Stefan Lippers-Hollmann <s.L-H at gmx.de> 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
> 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.
The decision which headers get shipped in linux-headers-$KVER is basically
made upstream by the mainline kernel developers, who are investing a lot
of time to clean up the userspace (and kernel) visible API.
in the install-headers_$(ARCH)_$(FEATURESET)_$(FLAVOUR) target.
> > 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.
This is definately not a preferred "solution", but may be a potential
result unless a fix can be found. Truth to be told, the required changes
are not simple and will have a larger impact on the modules' internal
design structure. Right now I am not sure (or confident) to fix this
particular bug soon, but will keep an eye on upstream development/ mailing
lists and give the lirc_gpio some more in depths review as soon as the
important bugs affecting all drivers and functionality as a whole  are
lirc just is basically a conglomeration package attempting to cover a whole
input subsystem with quite different devices, some of them requiring kernel
modules, some of them handled purely in userspace - some actively
maintained with large numbers of users, some barely maintained at all.
This doesn't mean lirc_gpio is about to be forgotten, but this issue goes
beyond a 'simple' compile fix for a slightly changing kernel API (the
symbols as a whole have been removed upstream in mainline kernel) and is
close to rewriting the module from scratch (yes, this is an exaggeration,
but not too far off), which is ideally handled by someone who actually has
access to this particular hardware and can debug the issue.
 in not particular order #450521, #393575, #433607, #456325, #369076
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20080328/73632f25/attachment-0001.pgp
More information about the Pkg-lirc-maint