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 https://www.debian.org/doc/debian-policy/ch-files.html#behavior, which says "[These scripts handling conffiles] must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens." https://wiki.debian.org/DpkgConffileHandling should help with figuring out how to do this properly. In https://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. From the attached log (scroll to the bottom...): Setting up logcheck (1.4.2) ... Configuration file '/etc/logcheck/header.txt' ==> File on system created by you or by a script. ==> File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** header.txt (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package logcheck (--configure): end of file on stdin at conffile prompt Processing triggers for debianutils (5.7-0.5~deb12anbe1) ... Processing triggers for libc-bin (2.36-9) ... Errors were encountered while processing: logcheck This happens up upgrade paths starting in jessie, upgrading release by release to bookworm. cheers, Andreas
header.txt has not been modified since 2015. it is a simple yext file that is installed with debian/logcheck.install the only change is that it used to be installed into /usr/share but got moved to /etc to be a conffile in 2021. This didnt trigger any piuparts issues and there was no change to the contents of header.txt. So i dont understand how piuparts found an issue - is it possible to tell us what difference piuparts actually detected?
header.txt has not been modified since 2015. it is a simple yext file that is installed with debian/logcheck.install the only change is that it used to be installed into /usr/share but got moved to /etc to be a conffile in 2021. This didnt trigger any piuparts issues and there was no change to the contents of header.txt. So i dont understand how piuparts found an issue - is it possible to tell us what difference piuparts actually detected?
Control: tag -1 patch * lenny * squeeze, wheezy, jessie * stretch .. today It has been copied during initial install only and was never upgraded. If the system was installed before stretch, the header.txt does not match the current one and dpkg will complain when replacing it with a proper conffile. test, testing every package starting from jessie (or even earlier) and upgrading release by release to testing takes a lot of time (and didn't finish before the release happened), but sometimes reveals interesting things ;-) Attached patch should fix this long upgrade path. The preinst checks whether header.txt matches a known shipped (but not current) variant and tries to update it to the current variant. It seems to work fine when starting from jessie, more tests will be running over night. Andreas PS: please don't mix this fix with other changes not intended for bookworm, s.t. it can go to sid as 1.4.3 and be rebuilt for bookworm as 1.4.3~deb12u1 in order not to break the version constraints
New version of the patch fixing a wrong checksum. Now logcheck upgrade paths starting from ancient releases look clean ;-) Andreas
thank-you - i believe understand this now for reasons unknown, when debian introduced header.txt in 2014 it shipped header.txt in /usr/share/logcheck and copied it to /etc/logcheck in postinst on initial install. Only the file in /etc is ever used. editorial changes were then made, but these only made it into the copy in /usr/share and no steps were taken to update the file in /etc. So those upgrading have been using the old version, while new installs got the new version. This is probably against the spirit of policy but it doesnt look like anyone noticed. In bookworm logcheck puts header.txt file directly into /etc/logcheck like any other conffile. because the content hasnt changed since stretch, this didnt cause immediate issues. But people who first installed at an old version will get a confusing conffile prompt on upgrade to bookworm even though they had never edited the file and had upgraded to every stable release..wow! thank-you for this i have learned something Luckily the header.txt is purely cosmetic - so there shouldnt be other bugs from this!
I think you might be missing one md5sum - I found 4 versions in the git repos
#####################
for x in $(git log debian/header.txt | awk '/commit/{print $2}'); do
git show $x:debian/header.txt | md5sum ; done
d9206d89f2f8d85d346a23da90459862 -
a32fc12d69628d96756fd3af3f8b3ecd -
dbc1e8d136180d247b572f6a19c4e92e -
1bc54d3bfb0d1e61104d5780a318ced2 -
#####################
the top one being the current version, the middle two the same as you
found and the one at the end '1bc54...' is from a commit dated
2004-04-19 (which might mean when woody was stable, i think, although
this seems to be the date cvs2svn was run)
presumably, we can then remove all this in trixie (if anyone remembers)
https://salsa.debian.org/debian/logcheck/-/merge_requests/18 now has the patch for this On Thu, 29 Jun 2023 at 21:36, Richard Lewis <richard.lewis.debian@googlemail.com> wrote:
Andreas, thanks for the report, and Richard, thanks for your work as well. I think the changes look good, and if there's no other concerns I'll merge the salsa MR, and upload a new version to unstable. Once that's done, I'll also file a bug for uploading the updated version to stable-proposed-updates; I know the deadline for the first bookworm point release is this weekend, so it might get in for 12.1. Mathias
We believe that the bug you reported is fixed in the latest version of
logcheck, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1039591@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Mathias Gibbens <gibmat@debian.org> (supplier of updated logcheck package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 18 Jul 2023 10:54:10 +0000
Source: logcheck
Architecture: source
Version: 1.4.3
Distribution: unstable
Urgency: medium
Maintainer: Debian logcheck Team <logcheck@packages.debian.org>
Changed-By: Mathias Gibbens <gibmat@debian.org>
Closes: 1039591
Changes:
logcheck (1.4.3) unstable; urgency=medium
.
[ Andreas Beckmann ]
* Add logcheck.preinst to update header.txt if it matches a
version shipped in old debian releases (woody-jessie), this avoid
dpkg complaining about a modified conffile for people who
installed logcheck in jessie or earlier (Closes: #1039591).
Checksums-Sha1:
5aff5d5168413dc338a33021721571433db641ec 1836 logcheck_1.4.3.dsc
0e8c29dcec9589075af2bea6f3bd2d0c382f166c 138740 logcheck_1.4.3.tar.xz
18586a92a9722b4f3237c77eeaa5b09cc0ffb61b 6735 logcheck_1.4.3_amd64.buildinfo
Checksums-Sha256:
468b9e34ec8151c255670079afa1a08d32a79da35e0abc75690d0348bcf7bf2b 1836 logcheck_1.4.3.dsc
ad83ae80bd780bdae5eefd40ad59a3e97b85ad3a4962aa7c00d98ed3bdffcdd0 138740 logcheck_1.4.3.tar.xz
0c6c77fd76389ad9273fad395777f120797f2e9528608f975de0638dc30ce041 6735 logcheck_1.4.3_amd64.buildinfo
Files:
537ae1ccb9c9fb9935a09ec790f60d73 1836 admin optional logcheck_1.4.3.dsc
1404ecaa435572fa6f1924282bf27aa9 138740 admin optional logcheck_1.4.3.tar.xz
719b2457232d2f57cfbd6f2b3ebd1b00 6735 admin optional logcheck_1.4.3_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJGBAEBCgAwFiEE1Bp60H32xfynSJ8cKe7i1uz0QvkFAmS2cAASHGdpYm1hdEBk
ZWJpYW4ub3JnAAoJECnu4tbs9EL55n8P/0hI/2eiVuV9Ic7KqSPEbq8NhHATnkGQ
3Bcq/IAdssd6lQQCE+fLoNcHzpFRo0RFGRBwpYEh4e5xsbhf+5bnoDQkLxyOBlrp
inLoUhVClg94UZLyKttXperydaNRLuJU15lOBTQ/G2F04CB2sI1bv2n09xvXRvr5
jvtOGsHIeYSPokvJGc76n8C3puLZGE2zMp2q0aWqKshk7xljNOJxTzenszACfonf
QM8096txSyrVVBLsVZY4CCIocdk4Nm6Evmzb/dNaMMm9lZMD1SDn6xVanrZgrcW6
vCpX7FtiaXGvAfq+Y0sVqjKI9RXEsYcPmu/8rQivQatkO3qMsdImMQmgebnNTX6s
nrGGlRhgltixMFHFjDa9paHUknuKuvKU0PNY600zp+sHvUkQ2vuu60cMhGnK8CtJ
EjWvWsdPAfJZz+x2PEvx3/Effzo2+qAXCeF3U8xZHCJURZaEt3cEgYxSQcNVHspk
NlILFZN4EANYlTZrNYkjUBHhZXEyfM1Sec+uOQQjZLc/hWwCLoDl7Jf+WKmONp61
qq1YpBq14pbo0JAb5jvK3vafPKSHLv0ZnqSu1ob6EMTNDsKV8Tv9i0tXbJLFGzLm
MD1paB4rTOvoaj81TWcHFkjjxapeXZMpjerh38kjpkT90EQBLgR3P4zMDOlm4bUH
Qo7vzv9gEmYV
=XPQw
-----END PGP SIGNATURE-----
A gentle reminder on the last bit of this - getting it into bookworm point release. (i think i read somewhere that 12.2 would be at the end of august)
El 29/6/23 a las 22:20, Richard Lewis escribió: when there is a default which satisfies everybody (or almost everybody). In this case there will be people who will be happy with the default header.txt, but there will also be people (like me) who prefer not to have any header.txt at all. In my opinion header.txt is one of those files where it is much better not to be handled via the conffile mechanism. I've just filed a separate bug for that (#1049412), since deletion is currently unsupported and it should be. Note: I see there is a "md5sum framework" in place to update the file in case it's necessary. I have a similar md5sum framework in base-files.postinst and it works very well. With this framework already in place, I would hope that switching to the old way of handling header.txt should be easy enough. Thanks.