[Pkg-lirc-maint] Bug#436166: Bug#436166: Bug#436166: Progress notes

[Stefan Lippers-Hollmann]

[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
> 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.

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.

cf. http://svn.debian.org/viewsvn/kernel/dists/trunk/linux-2.6/debian/rules.real?rev=10983&view=markup
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.
>   Cheers.

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 [1] are 
fixed.

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.

Regards
	Stefan Lippers-Hollmann

[1]	in not particular order #450521, #393575, #433607, #456325, #369076
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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