Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Control: tags -1 squeeze wheezy Hi, On Sun, Mar 23, 2014 at 11:16:26PM +, Stefan Lippers-Hollmann wrote: > > Anyway, as the postinst in wheezy does not appear to modify the config > > file, it appears that further upgrades should not have this problem. > > Given that the bug was tagged squeeze-ignore and wheezy-ignore, perhaps > > it can now be closed? > > I certainly won't object against closing this bug, especially as > neither squeeze nor wheezy will be changed in this regard anymore > (most users actually using lirc, would have needed to adapt their > configuration for kernel >= 2.6.37 anyways[2], when lirc was merged > into the kernel and several modules moved from lirc to RC_CORE). > However technically speaking, squeeze is still supported until roughly > 2014-05-06 (depending on the actual EOL date to be announced by the > stable release team) - and squeeze to wheezy upgrades also remain > affected. While technically not correct either, it might make sense to > drop its severity below the RC threshold though, to avoid bug squashers > from wasting time on this though. > > On the other hand there will be an upload, with the afforementioned bug > closures soon (for some value of 'soon', probably before the middle of > the year), which requires some adaptions to these pending changes (in > order to provide native systemd units, the sysv initscripts will have > to be split into individual initscripts for lirc, lircmd and irexec, so > the (to be added) systemd units can mask the corresponding initscripts > properly[3]) - and it's best to avoid needless/ forseeable conffile > churn until this is settled. As the bug is present in version 0.9.0~pre1-1, which is in wheezy, jessie and sid, but apparently doesn't affect jessie and sid, it probably makes sense to use release tags to indicate which releases are affected by this bug. This will indicate that the bug doesn't affect jessie, but it does affect squeeze and wheezy (even though it's also ignored for both releases). When the actual upload happens, version tracking will be updated, indicating that the newer version also isn't affected. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Hi On Sunday 23 March 2014, Ben Hutchings wrote: > Some time ago you committed: > > r497 | slh-guest | 2012-02-23 12:20:25 + (Thu, 23 Feb 2012) | 1 line > > detection stages (Closes: #660956). > > Index: debian/changelog > === > --- debian/changelog(revision 496) > +++ debian/changelog(revision 497) > @@ -88,7 +88,7 @@ > lirc 0.7.1pre2-8, previous versions unconditionally started an > interactive > non-debconf hardware detection/ selection menu, which always left > hardware.conf modified; md5sums for prior versions apply to aborted h/w > -detection stages. > +detection stages (Closes: #660956). > > -- Stefan Lippers-Hollmann Sat, 28 Jan 2012 20:03:16 +0100 > > > I think you actually meant to close #655969. Thanks for noticing this, I didn't match up to the bug closure with the correct changelog entry when the bug was filed after the actual change had already been done long before. Given that both bugs will be fixed in the same version, the actual effects would have been limited, but I've fixed it (and removed a duplicate bug closure) in [1]. > Anyway, as the postinst in wheezy does not appear to modify the config > file, it appears that further upgrades should not have this problem. > Given that the bug was tagged squeeze-ignore and wheezy-ignore, perhaps > it can now be closed? I certainly won't object against closing this bug, especially as neither squeeze nor wheezy will be changed in this regard anymore (most users actually using lirc, would have needed to adapt their configuration for kernel >= 2.6.37 anyways[2], when lirc was merged into the kernel and several modules moved from lirc to RC_CORE). However technically speaking, squeeze is still supported until roughly 2014-05-06 (depending on the actual EOL date to be announced by the stable release team) - and squeeze to wheezy upgrades also remain affected. While technically not correct either, it might make sense to drop its severity below the RC threshold though, to avoid bug squashers from wasting time on this though. On the other hand there will be an upload, with the afforementioned bug closures soon (for some value of 'soon', probably before the middle of the year), which requires some adaptions to these pending changes (in order to provide native systemd units, the sysv initscripts will have to be split into individual initscripts for lirc, lircmd and irexec, so the (to be added) systemd units can mask the corresponding initscripts properly[3]) - and it's best to avoid needless/ forseeable conffile churn until this is settled. Regards Stefan Lippers-Hollmann [1] http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/changelog?r1=517&r2=518 [2] https://lists.debian.org/debian-backports/2012/04/msg00076.html [3] lirc's sysv initscripts are working fine under systemd's sysv compatibility mode, but native support needs further changes. signature.asc Description: This is a digitally signed message part.
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Some time ago you committed: r497 | slh-guest | 2012-02-23 12:20:25 + (Thu, 23 Feb 2012) | 1 line detection stages (Closes: #660956). Index: debian/changelog === --- debian/changelog(revision 496) +++ debian/changelog(revision 497) @@ -88,7 +88,7 @@ lirc 0.7.1pre2-8, previous versions unconditionally started an interactive non-debconf hardware detection/ selection menu, which always left hardware.conf modified; md5sums for prior versions apply to aborted h/w -detection stages. +detection stages (Closes: #660956). -- Stefan Lippers-Hollmann Sat, 28 Jan 2012 20:03:16 +0100 I think you actually meant to close #655969. Anyway, as the postinst in wheezy does not appear to modify the config file, it appears that further upgrades should not have this problem. Given that the bug was tagged squeeze-ignore and wheezy-ignore, perhaps it can now be closed? Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
[Note to RT: this is about adding a wheezy-ignore tag for #655969] Le vendredi 8 mars 2013 17:27:33, Stefan Lippers-Hollmann a écrit : > Hi > > On Friday 08 March 2013, Thomas Preud'homme wrote: > > Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit : > […] > > > > On Thursday 07 March 2013, Thomas Preud'homme wrote: > […] > > > > 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). > > > > Great, I've been suggested to add a test for the version being upgraded > > from and testing if the file exist. Once done, I'll upload it (should be > > today or sunday). > > ack, thanks a lot. > > > > 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=mark > > > > > up or > > > > > > https://lists.debian.org/debian-backports/2012/04/msg00076.html > > > > > > for background information. > > > > Ack, the patch is not as useful as it could be. Can't lirc be installed > > by a Recommends dependency? If yes, it might be that the package is not > > of interest of the user and this message would thus annoy him/her. If > > lirc is on the contrary always installed when the user intend to use it, > > then the best approach is probably to tag it wheezy-ignore. It would be > > an even smaller change than this patch. > > [detailed analysis below, feel free to skip this list] > The rdepends of lirc, excluding packages built from the lirc source > package itself, are: > - vdr Video Disk Recorder for DVB cards > Recommends: lirc, ttf-bitstream-vera | ttf-freefont > vdr has three different ways of navigation (channel selection, lirc > is probably the most important one which always works (provided you > have properly configured hardware), keyboard based navigation is only > possible through selected frontends (e.g. xineliboutput-sxfe, only > this special frontend can transport key presses to the vdr dæmon) or > web based, through e.g vdr-plugin-live. > This makes it, while not mandatory, rather likely that a vdr user > also uses lirc hardware; it's probably a wishlist bug that vdr > doesn't have an alternative recommends on inputlirc (an alternative > lircd implementation) > - inputlirc Zeroconf LIRC daemon using input event devices > Suggests: lirc, input-utils > not pulled in automatically, the suggests looks weird at a first > glance (as inputlirc can provide a full lircd replacement for a > subset (only event based-) devices also supported by lircd, but the > reasons for this are the supporting tools of the lirc package (mostly > irw, to generate button <--> keycode mappings, eventually irexec). > Technically speaking, it might make sense to split out these tools > out of the lirc package, but that would leave lircd/ lircmd in a tiny > package of their own - something ftp-master doesn't exactly prefer. > - kremotecontrol frontend for using remote controls > Recommends: lirc > This one is a tough call, isolated to kremotecontrol, the Recommends > is correct, but kremotecontrol is a hard dependency of kdeutils (meta > package, probably installed for most KDE users), which in turn is a > hard dependency of kde-full… > Besides the typical lirc | inputlirc suggestion, this may be a larger > cause for lirc installations even if the user actually has not need > for it; it's also a relatively new dependency, as its KDE3 > predecessor -kdelirc- was not part of kdeutils at the time. > Technically the dependency chain is totally correct and weakening it > wouldn't be a logical conclusion for these meta packages, but given > the "lirc is only useful, if you have special, non-standard hardware" > (an IR receiver and a remote to use it) a suggests might be more in > order. > kremotecontrol didn't exist in squeeze, only its predecessor kdelirc, > which was a seperate source package and not part of kdeutils; it was > only suggested by kdetv, no hard dependencies or recommends. Yes this one. I had a vague memory of lirc being installed for me with KDE but I wasn't sure I could trust my memory. Thank you for the apt-rdepends foo :) > > […] > > Pulling in the lirc (or inputlirc for that matter) package, which means > the dæmon, without a strong indication that the user actually owns IR > receivers/ transceivers and wants to use them is most likely a bug. > lirc (or inputlirc) cannot do anything useful, unless properly > configured, which means at least selecting the driver type (out of ~60 > options - userspace and staging drivers, most of them can't be > autoprobed), specifying the device node it should listen on (in many
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Hi On Friday 08 March 2013, Thomas Preud'homme wrote: > Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit : […] > > On Thursday 07 March 2013, Thomas Preud'homme wrote: […] > > 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). > > Great, I've been suggested to add a test for the version being upgraded from > and testing if the file exist. Once done, I'll upload it (should be today or > sunday). ack, thanks a lot. > > 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=mark > > up or > > https://lists.debian.org/debian-backports/2012/04/msg00076.html > > for background information. > > Ack, the patch is not as useful as it could be. Can't lirc be installed by a > Recommends dependency? If yes, it might be that the package is not of > interest > of the user and this message would thus annoy him/her. If lirc is on the > contrary always installed when the user intend to use it, then the best > approach is probably to tag it wheezy-ignore. It would be an even smaller > change than this patch. [detailed analysis below, feel free to skip this list] The rdepends of lirc, excluding packages built from the lirc source package itself, are: - vdr Video Disk Recorder for DVB cards Recommends: lirc, ttf-bitstream-vera | ttf-freefont vdr has three different ways of navigation (channel selection, lirc is probably the most important one which always works (provided you have properly configured hardware), keyboard based navigation is only possible through selected frontends (e.g. xineliboutput-sxfe, only this special frontend can transport key presses to the vdr dæmon) or web based, through e.g vdr-plugin-live. This makes it, while not mandatory, rather likely that a vdr user also uses lirc hardware; it's probably a wishlist bug that vdr doesn't have an alternative recommends on inputlirc (an alternative lircd implementation) - inputlirc Zeroconf LIRC daemon using input event devices Suggests: lirc, input-utils not pulled in automatically, the suggests looks weird at a first glance (as inputlirc can provide a full lircd replacement for a subset (only event based-) devices also supported by lircd, but the reasons for this are the supporting tools of the lirc package (mostly irw, to generate button <--> keycode mappings, eventually irexec). Technically speaking, it might make sense to split out these tools out of the lirc package, but that would leave lircd/ lircmd in a tiny package of their own - something ftp-master doesn't exactly prefer. - kremotecontrolfrontend for using remote controls Recommends: lirc This one is a tough call, isolated to kremotecontrol, the Recommends is correct, but kremotecontrol is a hard dependency of kdeutils (meta package, probably installed for most KDE users), which in turn is a hard dependency of kde-full… Besides the typical lirc | inputlirc suggestion, this may be a larger cause for lirc installations even if the user actually has not need for it; it's also a relatively new dependency, as its KDE3 predecessor -kdelirc- was not part of kdeutils at the time. Technically the dependency chain is totally correct and weakening it wouldn't be a logical conclusion for these meta packages, but given the "lirc is only useful, if you have special, non-standard hardware" (an IR receiver and a remote to use it) a suggests might be more in order. kremotecontrol didn't exist in squeeze, only its predecessor kdelirc, which was a seperate source package and not part of kdeutils; it was only suggested by kdetv, no hard dependencies or recommends. - freevo-lirc home theater framework - LIRC support Depends: freevo (= 1.9.2b2-4.2), python-pylirc, lirc This one seems to be fine, no rdepends - not even a suggestion from any other package. (disclaimer, I've never used freevo) - enna a powerful MediaCenter application based on EFL Suggests: lirc only a suggests, so no issue here. (disclaimer, I've never used enna) - banshee-extension-lircLIRC integration extension for Banshee Depends: banshee-extensions-common (= 2.4.0-1), lirc, libc6 (>= 2.2.5), liblircclient0, libmono-corlib4.0-cil (>= 2.10.1) A recommends of banshee-community-extensions, a meta package, which in turn has no rdepends, this may be slightly inflate the number of unneeded lirc installations, but I'm not sure of how commonly this meta package is in the banchee community - probably the same Depends vs Suggests considerations as for kdeutils above apply. (dis
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit : > 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). Great, I've been suggested to add a test for the version being upgraded from and testing if the file exist. Once done, I'll upload it (should be today or sunday). > > 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=mark > up or > https://lists.debian.org/debian-backports/2012/04/msg00076.html > for background information. Ack, the patch is not as useful as it could be. Can't lirc be installed by a Recommends dependency? If yes, it might be that the package is not of interest of the user and this message would thus annoy him/her. If lirc is on the contrary always installed when the user intend to use it, then the best approach is probably to tag it wheezy-ignore. It would be an even smaller change than this patch. > > 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. If lirc is always installed to be used (never pulled by a Recommends), then tag it wheezy-ignore is probably the best approach indeed. Thanks for the background. > > Thanks a lot. > > Regards > Stefan Lippers-Hollmann > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=14;bug=655969 Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
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 ;;
Bug#655969: [Pkg-lirc-maint] Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Updated patch with (much) more comments. Thomas diff -Nru lirc-0.9.0~pre1/debian/changelog lirc-0.9.0~pre1/debian/changelog --- lirc-0.9.0~pre1/debian/changelog 2011-03-06 22:16:30.0 +0100 +++ lirc-0.9.0~pre1/debian/changelog 2013-03-07 16:58:28.0 +0100 @@ -1,3 +1,11 @@ +lirc (0.9.0~pre1-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Avoid prompt when conffiles are not modified by the system administrator +(Closes: #655969). + + -- Thomas Preud'homme Tue, 12 Feb 2013 18:24:27 +0100 + lirc (0.9.0~pre1-1) unstable; urgency=low [ Sven Mueller ] diff -Nru lirc-0.9.0~pre1/debian/lirc.preinst lirc-0.9.0~pre1/debian/lirc.preinst --- lirc-0.9.0~pre1/debian/lirc.preinst 1970-01-01 01:00:00.0 +0100 +++ lirc-0.9.0~pre1/debian/lirc.preinst 2013-03-07 17:15:35.0 +0100 @@ -0,0 +1,36 @@ +#!/bin/sh + +set -e + +case "$1" in + upgrade) + oldconfmd5=$(md5sum /etc/lirc/hardware.conf | cut -d ' ' -f 1) + # In Squeeze, lirc's postinst empties the value of DRIVER + # from /etc/lirc/hardware.conf if the value equals + # "UNCONFIGURED". Since this file defaults to "UNCONFIGURED", + # it is subsequently modified by the postinst. + # + # The code below check whether the md5 of the file matches the + # one of the file after a default install. If that is the case, + # the code reverts the change made by the postinst to prevent + # asking questions to the administrator when no file were + # modified. + if [ "$oldconfmd5" = "566ee1cfca73380a6ec4af14c7d874cd" ] + then + sed -i "s/^\(DRIVER\)=\"/\1=\"UNCONFIGURED/" /etc/lirc/hardware.conf + fi;; + install|abort-upgrade) + ;; + + *) + echo "preinst called with unknown argument \`$1'" >&2 + exit 1 + ;; +esac + +# dh_installdeb will replace this with shell code automatically +# generated by other debhelper scripts. + +#DEBHELPER# + +exit 0 signature.asc Description: This is a digitally signed message part.
Bug#655969: [Pkg-lirc-maint] Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
How many times will I forget to attach a file? Sorry. Thomas diff -Nru lirc-0.9.0~pre1/debian/changelog lirc-0.9.0~pre1/debian/changelog --- lirc-0.9.0~pre1/debian/changelog 2011-03-06 22:16:30.0 +0100 +++ lirc-0.9.0~pre1/debian/changelog 2013-02-12 18:25:50.0 +0100 @@ -1,3 +1,10 @@ +lirc (0.9.0~pre1-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Avoid prompt when conffiles are not modified (Closes: #655969). + + -- Thomas Preud'homme Tue, 12 Feb 2013 18:24:27 +0100 + lirc (0.9.0~pre1-1) unstable; urgency=low [ Sven Mueller ] diff -Nru lirc-0.9.0~pre1/debian/lirc.preinst lirc-0.9.0~pre1/debian/lirc.preinst --- lirc-0.9.0~pre1/debian/lirc.preinst 1970-01-01 01:00:00.0 +0100 +++ lirc-0.9.0~pre1/debian/lirc.preinst 2013-03-07 15:51:25.0 +0100 @@ -0,0 +1,26 @@ +#!/bin/sh + +set -e + +case "$1" in + upgrade) + oldconfmd5=$(md5sum /etc/lirc/hardware.conf | cut -d ' ' -f 1) + if [ "$oldconfmd5" = "566ee1cfca73380a6ec4af14c7d874cd" ] + then + sed -i "s/^\(DRIVER\)=\"/\1=\"UNCONFIGURED/" /etc/lirc/hardware.conf + fi;; + install|abort-upgrade) + ;; + + *) + echo "preinst called with unknown argument \`$1'" >&2 + exit 1 + ;; +esac + +# dh_installdeb will replace this with shell code automatically +# generated by other debhelper scripts. + +#DEBHELPER# + +exit 0 signature.asc Description: This is a digitally signed message part.
Bug#655969: [Pkg-lirc-maint] Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
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. Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Bug#655969: [Pkg-lirc-maint] Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
On Sat, 2013-01-26 at 18:22 +, Jonathan Wiltshire wrote: > 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... You're looking at the install count for liblircclient0, which many media players depend on. The conffiles belong to lirc, which has an install count of 5609 - not quite as big a problem. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#655969: [Pkg-lirc-maint] Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
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... -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits signature.asc Description: Digital signature
Bug#655969: [Pkg-lirc-maint] Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Hi On Tuesday 17 January 2012, Holger Levsen wrote: > Package: lirc > Version: 0.9.0~pre1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed the piuparts > upgrade > test because dpkg detected a conffile as being modified and then prompted the > user for an action. As there is no user input, this fails. But this is not > the real problem, the real problem is that this prompt shows up in the first > place, as there was nobody modifying this conffile at all, the package has > just been installed and upgraded... > > This is a violation of policy 10.7.3, see > http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3, which > says "[These scripts handling conffiles] must not ask unnecessary questions > (particularly during upgrades), and must otherwise be good citizens." > > http://wiki.debian.org/DpkgConffileHandling should help with figuring out how > to do this properly. > > In http://lists.debian.org/debian-devel/2009/08/msg00675.html and followups > it > has been agreed that these bugs are to be filed with severity serious. […] 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. Due to historically problematic config handling and several upstream changes requiring further adaptions to initscript and config, it will require slightly larger and more invasive changes than I would have been comfortable with for wheezy. Especially given that the kernel modules were finally merged mainline, but partly changed module names and/ or behaviour (switching to the new RC_CORE kernel subsystem). Actual users of several classic lirc modules (mceusb/ mceusb2, i2c, etc.) will have to do manual config changes (hardware.conf and lircd.conf key mappings, mostly not prompted for by debconf) as part of the wheezy upgrade - only few of these changes can be migrated automatically - for others nothing will change… But I will make sure that at least upgrades for unconfigured/ default lirc(d) installations won't trigger the conffile dialogues anymore. Basic plan: - dissolve /etc/lirc/hardware.conf and (semi-automatically) migrate relevant parts of its knowledge to /etc/default/lirc, using a slightly different configuration syntax (this is a topic on lirc upstream's whishlist for distro packaging anyways). - deprecate, but support for wheezy(?), (kernel-) module loading through /etc/lirc/hardware.conf and warn about it. Modern devices are autoprobed by udev, old-style ones (bt829, serial, sir, parallel, zilog) are recommended to be loaded by the local administrator (manual addition to /etc/modules). - properly deal with new style devices supporting both the old lirc protocol and different protocols of the new RC_CORE subsystem (like RC-5/ RC-6/ NEC/ jvc/ sony/ mce_kbd/ other and lirc, eventually resulting in key events detected twice). However these changes will require very careful upgrade- and regression testing on several hardware classes (kernel old-style, kernel new-style, kernel new-style with multiple supported protocols, userspace driver) and might take a little longer than I'm personally comfortable with for an RC bug. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
