Bug#1042049: lintian: FTBFS: 3 tests failed
On Thu, 7 Dec 2023 22:05:29 +1300 Vladimir Petko wrote: > As of today there are more test failures: > Test Summary Report > --- > debian/test-out/eval/checks/documentation/manual/manpage-errors-from-man/generic.t > debian/test-out/eval/checks/documentation/manual/surplus-manpage/generic.t > debian/test-out/eval/checks/documentation/manual/manpages-general/generic.t think these are already fixed in git > debian/test-out/eval/checks/systemd/kill-mode-none/generic.t (etc). This MR fixes these failures: https://salsa.debian.org/lintian/lintian/-/merge_requests/487 these are all because of usrmerge putting service files in usr/lib/systemd rather than lib/systemd -- add "usr/" to the message in the hints file for each (and updates the description of the tests in CONTRIBUTING.md and t/recipes/README) It also includes https://salsa.debian.org/lintian/lintian/-/merge_requests/485 Thanks for considering
Bug#1053898: Hardening rsyslog.service breaks debian/tests/logcheck autopkgtest
On Fri, 13 Oct 2023 at 20:27, Michael Biebl wrote: > It turns out that `PrivateTmp=yes` breaks the logcheck autopkgtest. i think the test tells rsyslog to write to /tmp and then calls logcheck on the output outside the unit. But the PrivateTmp=true means rsyslog is actually writing to [somewhere else] bind-mounted over /tmp. It should be easy to fix by making the test use /var/log instead of /tmp - will check and send a MR
Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt
On Wed, 12 Jul 2023 at 12:20, Mathias Gibbens 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; 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) -- let me know if there's anything i can do to help with this (i couldn't find anything listing what it involves!) im about to set up a merge request to add a systemd timer, and have some other changes in mind, but think we should get this bit done first
Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt
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
wrote:
>
> 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)
>
> On Wed, 28 Jun 2023 at 13:29, Andreas Beckmann wrote:
> >
> > New version of the patch fixing a wrong checksum. Now logcheck upgrade
> > paths starting from ancient releases look clean ;-)
> >
> > Andreas
Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt
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)
On Wed, 28 Jun 2023 at 13:29, Andreas Beckmann wrote:
>
> New version of the patch fixing a wrong checksum. Now logcheck upgrade
> paths starting from ancient releases look clean ;-)
>
> Andreas
Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt
On Tue, 27 Jun 2023, 22:01 Andreas Beckmann, wrote: > Control: tag -1 patch > > On 27/06/2023 19.21, Richard Lewis wrote: > > header.txt has not been modified since 2015. > > I've found three versions (with sightly different spelling): > * lenny > * squeeze, wheezy, jessie > * stretch .. today > > > 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. > > It has been copied during initial install only and was never upgraded. 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! >
Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt
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? On Tue, 27 Jun 2023, 15:30 Andreas Beckmann, wrote: > Package: logcheck > Version: 1.4.2 > 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 > 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 >
Bug#1031786: logcheck: Filtering not working with entries from journald
On Wed, 22 Feb 2023, 17:51 Helge Kreutzmann, wrote: > Package: logcheck > Version: 1.4.1 > Severity: grave > Justification: renders package unusable > > The change for #1025719 broke logcheck massively. > > I've extensivly tuned logcheck files which nicely filter out lots of > messages (see statistics at the end). > > Now I see them all again (only those comming from the journal). > > I don't see any information what I should do for migration. > sorry about that. i agree there is a bug in the documentation - we should add a NEWS.Debian entry - my fault i simply forgot. But this is hardly a grave bug. It is trivial to disable checking of the journal. just edit /etc/logcheck/logcheck.logfiles.d/journal.logfiles and add a # before the word "journal". this will take effect on the next run of logcheck. This is also documented in that file --- as a heavy logcheck user i would recommend reading new config files when installing a new version. (We dont plan more changes for bookworm but in the longer-term there could be some changes to make logcheck more efficient) HOWEVER, you might want to consider adjusting to this in the long-term - if your log messages are different in the journal and syslog then not checking the journal means you are by definition not being informed of things. That would rather seem to defeat the point of monitoring the log messges. But it is of course up to you. But given debian has demoted syslog logcheck does need to "move with the times" and support systemd by default - we will not force anyone to adapt, but we cant predict what settings work for you. Let's use a trivial example. The following harmless message is emitted > by courier to the journal: > Feb 22 16:37:40 meinfjell courierd[401638]: Installing uucp > > In syslog this is: > syslog:2023-02-22T14:37:40.491690+00:00 meinfjell courierd: Installing uucp > > I have the following in > /etc/logcheck/ignore.d.server: > meinfjell courierd: Initializing uucp Is this a typo? this rule is not going to filter that message regardless of whether it is in the journal or syslog. one says initiailizing one says installing (Maybe courier changed its logging? ) I also note you have the "new" timestamp format for syslog- that's an rsyslog change and nothing to do with logcheck. I believe you can revert that change quite easily as well. As you can see, the message from the journal is slightly different > than from syslog, breaking tons of rules. > that sounds like a bug in courier. As above you can choose to only check one source of messages. Most programs put the same messages in both in my experience. > For statistics: > On my local system, I have 11396 lines of rules, on my server system > currently 2721 (I'm in the processing of setting this up, so this will > grow). > wow! but yes, logcheck-databse does need a lot of manual tuning to be useful. (I am surprised it copes with thay many lines tbh!) sorry again for the inconvenience.
Bug#1002522: chkrootkit: autopkgtest failure everywhere except amd64
control: fixed -1 0.55-4 thanks On Thu, 23 Dec 2021 21:36:11 +0100 Paul Gevers wrote: > So let's assume the results will be OK, then you can just close this bug > with fixed version 0.55-4 and ignore it further. Thanks, it seems 0.55-4 is indeed testing fine everywhere, according to the latest https://tracker.debian.org/pkg/chkrootkit R
Bug#999082: offering to help with checksecurity
Hi, I don't know how much attention this package gets, but i still use it The repository at https://salsa.debian.org/rpil2/checksecurity/ includes a 'modernised' 3-line debian/rules (plus other things) that would, i think, fix this bug. That repository includes all the history that git-buildpackage could import, and makes various other changes - i really wanted to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994707 but . I ended up doing more, including rewriting the main perl script in bash and fixing some other inconsistencies and logfile locations - so you might not want all of what is in there, but perhaps it is helpful. If there is another/better way to help keep this package in Debian do let me know - as ever, i find myself not really sure how to help.
Bug#948706: Polite ping
Is there a recommended alternative way to implement greylisting with exim? On Wed, 3 Jun 2020 at 14:18, Eugene Berdnikov wrote: > > Hi. > > On Wed, Jun 03, 2020 at 02:01:33PM +0200, Benedikt Spranger wrote: > > Hi, > > > > are there any updates or is more help needed? > > Unfortunately, this package seems to be not maintained. > -- > Eugene Berdnikov > > -- > To unsubscribe, send mail to 948706-unsubscr...@bugs.debian.org.
Bug#306595: tetex-bin: postinst failure with jadetex and xmltex
Laurent Bonnaud [EMAIL PROTECTED] writes: here is the problem: Setting up tetex-bin (3.0-3) ... Merging information from /etc/texmf/texmf.d/ into /etc/texmf/texmf.cnf ... done Regenerating /var/lib/texmf/web2c/fmtutil.cnf ... done Running fmtutil-sys. This may take some time. ... Error: `tex -ini -jobname=jadetex -progname=jadetex latex jadetex.ini' failed Error: `tex -ini -jobname=xmltex -progname=xmltex latex xmltex.ini' failed ### fmtutil: Error! Not all formats have been built successfully. Visit the log files in directory /var/lib/texmf/web2c for details. ### This is a summary of all `failed' messages and warnings: `tex -ini -jobname=jadetex -progname=jadetex latex jadetex.ini' failed `tex -ini -jobname=xmltex -progname=xmltex latex xmltex.ini' failed Looks like jadetex problem #298437. What version of jadetex do you have installed (or was trying to be installed with tetex)? You need at least 3.13-4 to use tetex-3: jadetex (3.13-4) unstable; urgency=low . * Use e-tex instead of Knuth's TeX. This is needed for teTeX 3.0. (Closes: #298437). fmtutil: running `tex -ini -jobname=xmltex -progname=xmltex latex xmltex.ini' ... This is TeX, Version 3.141592 (Web2C 7.5.4) (INITEX) ---! /var/lib/texmf/web2c/latex.fmt was written by pdfetex (Fatal format file error; I'm stymied) definitely jadetex trying to create its format with Knuth's tex. Jadetex is now at 3.16 in testing, I suggest you do apt-get update and try again. [I'm not the maintainer, just an interested user] I guess tetex needs to conflict with old jadetex? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294895: dependency problems prevent configuration of a2ps
Package: a2ps Version: 1:4.13b-4.3 Severity: grave Justification: renders package unupgradeable (I hope the severity is appropriate; it's not exactly hard to fix the problem but clearly something needs to be fixed) When doing a apt-get dist-upgrade (from version 1:4.13b-4) I got the following error dpkg: dependency problems prevent configuration of a2ps: a2ps depends on emacsen-common; however: Package emacsen-common is not configured yet. dpkg: error processing a2ps (--configure): dependency problems - leaving unconfigured re-running apt-get dist-upgrade fixed things. emacsen-common was upgraded from 1.4.15 - 1.4.16 -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10-2005-01-22 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages a2ps depends on: ii emacsen-common 1.4.16 Common facilities for all emacsen ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libpaper1 1.1.14-3 Library for handling paper charact -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
