Hi On Sonntag, 1. Februar 2009, The Eclectic One wrote: > Package: lirc > Version: 0.8.3-3 > Severity: grave > Justification: renders package unusable > > # dpkg-reconfigure lirc > Stopping lirc daemon: irexec lircmd lircd. > .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation. > ################################################## > ## LIRC IS NOT CONFIGURED ## > ## ## > ## read /usr/share/doc/lirc/html/configure.html ## > ################################################## > Additional hint: Either /etc/lirc/lircd.conf or > /etc/lirc/hardware.conf doesn't exist or either > of the two has the string UNCONFIGURED in it at > some important place. Try: 'dpkg-reconfigure lirc' > Starting lirc daemon:. > > But lircd is never started. Trying the same command again results in > the same messages and lirc is still not configured. In fact, > /etc/lirc/lircd.conf begins with #UNCONFIGURED (both files > referenced in the error message above exist). It seems counter-intuitive > that configuring the package doesn't actually do it. Shouldn't the > dpkg-reconfigure scripts do what lirc needs to work properly, and > mark it as configured (ie: removing the #UNCONFIGURED line)? > > This is on a new Lenny installation on a blank disk, so there are no > leftovers from previous versions. I'll do whatever testing is > required if the problem can't be isolated. Just let me know.
Just to explain what Samuel Thibault has already mentioned, it is 100% impossible to do all steps required to set up lirc using debconf. On the one hand there are 16 (17 in lirc 0.8.4, even more with non upstream patches) kernel modules and 38 userspace drivers available, some of them could be autodetected (USB based ones and those who appear on the PCI bus), a lot cannot be detected at all (serial, parallel, gpio, sir). Some need special configuration (IRQ and memory address for serial, sir and parallel, path to an input device for devinput devices), making all of this selectable simply isn't a task for debconf and doing so would be worth a higher priority bug (debconf abuse) on its own. But even not looking at the receiver hardware itself (hardware.conf), automatically creating or allowing to select a matching lircd.conf is even more impossible, as you can mate (withing the limits of matching IR frequency between receiver and remote, but with broad overlaps in typical consumer devices) any IR receiver with any IR remote, not only the one shipped with your receiver, but just about any; shipped with lirc 0.8.3 are 61 templates for well known remotes at this moment, but nothing against repurposing you old VCR remote for lirc and mating it with a lirc_serial or lirc_atiusb or even a lirc_sir transceiver. Not even starting to talk about configuring several remotes with one receiver or even more than one receiver... If you'd find any solutiong to this, it won't be debconf by design ("debconf is not a registry"). So yes, you're in control and will have to open a text editor and start editing hardware.conf and either select, download or create (irrecord) a lircd.conf for your particular remote, lirc's initscript even tells you where to look for these config files, which do - in general, at least for the devices I know about - work and are rather well commented/ documented. Therefore I have a hard time understanding how this would "render[s] package unusable". That said, yes the debconf usage in lirc is questionable and in desperate needs of getting revised, actually a number of debconf questions are never asked anymore, because they're totally obsolete "Create LIRC device nodes if they are not there?", c'mon, that's udev's job (with a fallback to MAKEDEV for systems not using udev) or "Old configuration files found", pre-sarge (and I'm actually too lazy to find out when exactly this was added), "Delete /var/log/lircd?" (lirc logs to syslog for more than 2 releases already, again I'm too lazy to determine the actual date this changed), ... So while there is lots of stale information in lirc's debconf usage, none of these ever allowed configuring a device through lirc - I explained why this isn't possible in the first paragraph. Therefore reconfiguring lirc doesn't fail at all, postinst and debconf scripts execute perfectly fine - just (re-)starting /etc/init.d/lirc cannot succeed without a proper configuration, which is exactly what it prints to stdout/ stderr. Why hasn't this been cleaned up yet? Well, the answer to this is easy, there were much more important (real RC severity) fixes required before thinking about cosmetics, furthermore you don't start to redesign debconf templates 2-3 months before a freeze (or during a deep freeze, like now), at least not if there is no pressing need. The fact that the historic debconf usage doesn't adhere to established policy and packaging standards doesn't make this easier without breaking existing setups easier. Looking into the immediate future, there is lirc 0.8.4+ (which got released while lenny was already frozen and therefore didn't qualify for a freeze excemption) which does bring initial hal support for new fashioned receivers (those which can be found by udev) and will allow semi-automatic configuration for their hardware (not lircd.conf and neither for legacy receivers as lirc_serial, lirc_parallel, lirc_sir, lirc_gpio, etc.) and which enforces larger debconf (and packaging) changes. That said, following the exact wording of this bugreport, there isn't any bug at all, as you will "never" be able to configure lirc solely through debconf. But of course, the debconf usage within the lirc packaging needs a thourough clean up, which will actually result in a serious reduction (debconf is totally useless for lirc-modules-source, as there is a sane configuration for all (desktop) systems by compiling all kernel modules (embedded like systems can still influence the modules to be build through lirc-modules-source.conf), IRQ and port setting cann and should be done at module load time through modprobe.d) of debconf questions, not in extending (or "fixing") them. Regards Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.