Your message dated Sat, 8 Aug 2009 20:32:33 +0200
with message-id <[email protected]>
and subject line Re: [Pkg-lirc-maint] Bug#513769: dpkg-reconfigure lirc always 
fails
has caused the Debian Bug report #513769,
regarding should provide debconf templates to generate lircd.conf
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
513769: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513769
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lirc depends on:
ii  debconf [debconf-2.0]        1.5.24      Debian configuration management sy
ii  libasound2                   1.0.16-2    ALSA library
ii  libc6                        2.7-18      GNU C Library: Shared libraries
ii  liblircclient0               0.8.3-3     infra-red remote control support -
ii  libusb-0.1-4                 2:0.1.12-13 userspace USB programming library

lirc recommends no packages.

Versions of packages lirc suggests:
ii  lirc-modules-source           0.8.3-3    infra-red remote control support -
pn  lirc-svga                     <none>     (no description available)
pn  lirc-x                        <none>     (no description available)

-- debconf information:
  lirc/take_care_of_old_config:
  lirc/install_devices: true
  lirc/irq:
  lirc/lircd_conf:
  lirc/reconfigure: false
  lirc/lircmd_conf:
  lirc/remove_var-log-lircd: true
  lirc/driver:
  lirc/port:
  lirc/device:
  lirc/should-use-IntelliMouse:
  lirc/cflags:
  lirc/timer:
  lirc/modules:



--- End Message ---
--- Begin Message ---
Source: lirc

As explained in my last mail, it simply isn't possible to provide a 
completely debconf based method of configuration, not even for the most 
common combination of devices (which arguably doesn't even exist).

I'm closing this specific bug, as following exactly this bugreport there
is no bug. At the same time the debconf configuration needs to be 
overhauled, as requested in #162933 and this is required for the next lirc
version to be uploaded anyways. Likewise packaging lirc >= 0.8.4, as 
requested in #517507 will offer a hal based device detection for new style
devices that can be found by udev/ hal.

Therefore a number of issues mentioned will be taken into account with the 
next version, even if there is no real "fix" for this bugreport.

Regards
        Stefan Lippers-Hollmann

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---

Reply via email to