[Pkg-lirc-maint] LIRC package status/new maintainer offer

Wed Nov 17 02:29:43 UTC 2010

Hi

On Wednesday 17 November 2010, Eric Sharkey wrote:
[...]
> I've noticed that the Debian package of LIRC is quite out of date at
> this point and pleas for new versions (e.g. bug #517507, bug #548826)
> don't seem to be getting anywhere productive.

If you didn't notice yet, squeeze is in deep freeze by now - which means
uploading a new (vastly different) upstream version for a package with a 
shared library used by ~40 rdepends doesn't really qualify as freeze 
excemption.

Looking at the package's Vcs-Svn header¹, you'll notice that trunk 
packaging is at 0.9.0~pre1 and barely out-of-date, with the last 
changes committed just a week ago.

So why hasn't a new upstream version been uploaded before:
- because lirc >= 0.8.4 requires a different handling for hotpluggable
  devices, for which udev loads kernel modules on its own. No one in 
  the current team posses such hardware (lirc_igorplugusb, lirc_it87,
  lirc_ite8709, lirc_ttusbir or mceusb), my own attempts to buy a 
  mceusb based device failed, as what I received didn't use mceusb, 
  but emulated USB keyboard and mice and generates keycodes/ mouse 
  events without needing any (lirc-) kernel module and "just works" - 
  nice for using it, but bad if you wanted to debug hotpluggable/ 
  probable lirc devices.
- lirc >= 0.8.4 introduced an FTBS on kFreeBSD (release architectures),
  which got even worse in 0.8.7/ 0.9.0~pre1 and now also extends to 
  hurd-i386 (more _IOT__IOTBASE___u32 trouble, but this is fortunately
  not a release architecture), which I only had time to fix a good week
  ago.
- lirc 0.8.6 broke the kernel <-> userspace ABI between kernel modules
  and lircd(æmon), requiring that lirc-modules-{modules-,}$(uname -r)
  (a side effect of an historically bad package naming for 
  lirc-modules-source, hello NEW - but lirc 0.9.0 and kernel >=2.6.36
  obsoletes this package alltogether) are upgraded in lockstep
  (policy doesn't allow according dependecies/ breaks).
- lirc 0.9.0 (respectively the patched 0.8.7 in the packaging history)
  breaks this ABI once again, as the in-kernel staging lirc modules of 
  kernel >= 2.6.36 (or the still existing, but no longer needed, 
  out-of-tree copy of these drivers) need a different major/ minor 
  device numbers and because of a different ioctl interface.
- while not technically another ABI break, the existing lirc modules 
  merged mainline as staging are being actively ported towards ir_core,
  requiring yet another reconfiguring of affected devices with 2.6.37+.
- lirc packaging, and in particular the debconf usage (abuse), is 
  historically and utter mess and mostly broken since sarge/ kernel 
  2.6.8 (way before anyone of the current maintainers joind pkg-lirc),
  but fixing this without endangering the upgrade path is not exactly
  trivial. While this is not exactly rocket science, it needs careful
  and small iterations to not mess system upgrades (with a legacy back 
  to woody). lirc finally being merged mainline eases this up 
  tremenduously, basically obsoleting any kind of debconf anymore - but
  the existing (really horrible) debconf abuse needs to be carefully
  disabled and stored settings (again ranging back towards woody) 
  cleared.
- formal in-kernel ir_core support is affected (but not toally blocked)
  by #601279 against v4l-utils.
- kernel >= 2.6.36 would be preferred

Personally I really hoped for lirc 0.9.0 (or 0.8.7 plus upstream 
backports introducing the new in-kernel ioctl interface and device 
numbers, using an out-of-tree build of contemporary lirc modules) to 
get released in time for squeeze, avoiding the double userspace ABI 
breakage and profitting from a seriously easier situation for fighting
the debconf abuse (which was already partly covered for 
'lirc-modules-source' before, but requring further cleanup for 'lirc').
...but the announced freeze time for squeeze of "late august", suddenly
became 2010-08-06 - and lirc 0.8.7 (and especially 0.9.0) was delayed 
(much) longer than expected.

So what needs to be done for lirc, ignoring squeeze (the 'only' 
technical issue here is lirc_i2c, compatibility with a potential 
squeeze-and-a-half is totally impossible, without a full blown 
backport) as all mandatory fixes to comply with policy version 3.9.1 
are far beyond everything that would be acceptable as a freeze 
excemption? Let me quote from a private mail I answered a few days ago:
[...]
What can (and needs) to be done now:
- ripping out all of the flawed debconf handling, as it's no longer 
  necessary with all kernel modules being part of mainline (be it the 
  proper kernel --> ir_core or staging) - and has been broken since 
  sarge's 2.6.8 kernel anyways.
- cleaning up the convoluted maintainer scripts (with 
  lirc-modules-source being gone in 0.9.0~ and kernel 2.6.36, this is
  finally in reach, while not necessarily easy)
- simplifying and fixing up the initscripts, as much of it is pretty 
  fragile and overengineered.
- dealing properly with hotpluggable/ and auto-probed lirc devices,
  which is totally neglected in the exiting initscripts. Unfortunately
  I have no personal experience with these (like lirc_igorplugusb, 
  lirc_it87, lirc_ite8709, lirc_ttusbir and the totally new ir_core 
  based ones, like mceusb, ir-kbd-i2c, etc.).
- checking how much can modelled after Fedora's example, [..which are] 
  very actively [maintained by upstream].
- ...and the ubiquitous copyright/ license audit, which hasn't been
  high on the todo list by previous maintainers (and is not exactly
  easy for user-contributed lircd configs in /usr/share/lirc/remotes/)
- debugging the newly gained FTBS on hurd-i386 (low priority, as hurd 
  isn't a release architecture).
[...]

> If you don't have the time to work on this any longer, I would like to
> take over as maintainer of this package.  Please let me know how you
> would like to proceed.

I am working on lirc¹, but my available time (and in particular chunk 
size thereof) is unfortunately not as large as I'd like it to be and 
for new(ish) hotpluggable and autoloaded devices (exported device, ACPI
or platform IDs, likewise some devices handled by userspace can be 
detected by hal (R.I.P)) several adaptions are needed for the 
initscripts, which I cannot test myself. 

There have been several offers for help (and if you look at "recent" 
bugreports, you'll notice pretty specific issue lists in my answers) 
over the last 2 years, but none of these materialized into any kind of
commits or patches and the existing member list of the alioth project 
has little overlap with reality, so please forgive me, if I'm slightly 
sceptical; but help is definately appreciated at any layer.

Regards
	Stefan Lippers-Hollmann

[1]	Vcs-Svn:		svn://svn.debian.org/svn/pkg-lirc/lirc/trunk/
	Vcs-Browser:	http://svn.debian.org/viewsvn/pkg-lirc/lirc/trunk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20101117/f9b5b2c3/attachment.pgp>