Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user

[Stefan Lippers-Hollmann]

Hi

On Thursday 07 March 2013, Thomas Preud'homme wrote:
> tags 655969 + patch
> thanks
> 
> Le samedi 26 janvier 2013 19:22:23, Jonathan Wiltshire a écrit :
> > On Wed, Jan 18, 2012 at 01:34:08AM +0100, Stefan Lippers-Hollmann wrote:
> > > Thanks for the notice, while I don't exactly share that severity
> > > classification (although that is of course covered by the policy text),
> > > I'll work on this as soon as possible.
> > 
> > Ping? It's been a year, and with a popcon of over 60,000 a *lot* of people
> > are going to start seeing this prompt very soon...
> 
> What about this patch? It checks whether the md5 of the lirc/hardware.conf 
> conffile installed on the system matches the md5 of the file as modified by 
> the 
> postinst in an automatic install. If that is the case, it sets the file back 
> to 
> the content as shipped in the .deb package so that dpkg doesn't detect the 
> file 
> as modified.
> 
> I reproduced the bug in pbuilder and the bug disappear when using this patch.
[…]

Thanks for looking into this bug, the patch itself is correct and will 
avoid the reported piuparts upgrade issue (which is technically RC), so
please feel free to upload the NMU (I'd appreciate it). 

So far I misremembered the squeeze-ignore[1] being a wheezy-ignore tag 
instead, as a complete fix beyond the semi-synthetic "upgrade an 
unconfigured lircd installation" [which is of course a valid, but 
probably rare (lircd always needs to be configured manually, so 
packages depending on "lirc" can't assume it to work out of the box 
and there are alternative lircd implementations in the archive 
(inputlirc or using RC_CORE directly)), situation in the wild] would 
be too complex to be eligible for an unblock.


[Feel free to ignore the context explained below]

Just be aware that it only papers over a larger issue that forces
most lircd users actually driving various lirc hardware to reconfigure
their config file regardless of this change; please see
        
http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/NEWS?view=markup
or
        https://lists.debian.org/debian-backports/2012/04/msg00076.html
for background information.

Short summary:
        Many (previously out-of-tree) lirc modules have been merged 
        mainline into the new RC_CORE subsystem, which requires 
        configuration changes without forward/ backward compatibility,
        not fatal as in "breaks booting", but   the previously 
        configured IR remotes won't work unless reconfigured.

        This won't only haunt squeeze --> wheezy upgrades, but also 
        jessie; a couple of drivers already moved to RC_CORE after
        kernel 3.2 (be it previously staging drivers or ones acting 
        as mere event devices before), the staging lirc_bt829, 
        lirc_igorplugusb, lirc_imon, lirc_parallel, lirc_sasem, 
        lirc_serial, lirc_sir and lirc_zilog (and likely some further 
        IR receivers hiding in various TV card drivers but not using 
        the RC_CORE protocols) still have that fate in front of them…

Actually I have a similar change pending locally, as part of an 
attempt to migrate the configuration during upgrade automatically (for 
jessie, hardware.conf will go away in favour of a new /etc/default/lirc,
so this change would have removed known 'unmodified' variants of 
hardware.conf, rather than trying to fix them up):

                if [ -r /etc/lirc/hardware.conf ]; then
                        # remove known 'unconfigured' states of hardware.conf
                        case "$(md5sum -b /etc/lirc/hardware.conf)" in
                                c8e253e1b582f391ade003caf48087e5*)
                                        # lirc 0.6.5-1 up to << 0.6.6-12
                                        rm /etc/lirc/hardware.conf
                                        ;;
                                c3dbd1fc00722361e4e17f4622ee8c39*)
                                        # lirc 0.7.1pre2-8 up to 0.7.1pre2-9
                                        rm /etc/lirc/hardware.conf
                                        ;;
                                1b9d4706a023bb6c562357fa1ab50b95*)
                                        # lirc 0.6.6-12 up to 0.7.1pre2-7
                                        # lirc 0.7.1pre2-10 up to 0.8.0-12
                                        rm /etc/lirc/hardware.conf
                                        ;;
                                637160f0fafa2b0a703d46127c01f094*)
                                        # lirc 0.8.0-13 up to 0.8.2-1
                                        rm /etc/lirc/hardware.conf
                                        ;;
                                566ee1cfca73380a6ec4af14c7d874cd*)
                                        # lirc 0.8.3-2 up to 0.8.3-5
                                        # no hardware detected
                                        rm /etc/lirc/hardware.conf
                                        ;;
                        esac
                fi

For these reasons, I probably would have asked for a wheezy-ignore, in 
order to get a complete fix into jessie, rather than only fixing the 
reported bug. However your proposed nmudiff won't interfere with those
for-jessie changes and I'd appreciate if you could upload it.

Thanks a lot.

Regards
        Stefan Lippers-Hollmann

[1]     http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=14;bug=655969

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