Bug#1072801: ITP: lsix -- Show thumbnails in terminal using sixel graphics

[Richard Lewis]

Blair Noctis  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Blair Noctis 
> X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng
>
> * Package name: lsix
>   Version : 1.8.2
>   Upstream Contact: b9 
> * URL : https://github.com/hackerb9/lsix
> * License : GPL-3
>   Programming Lang: Shell
>   Description : Show thumbnails in terminal using sixel graphics
>
> Like "ls", but for images.

But ls works fine on images do you (and upsteam) mean "like 'cat'
but for images?"

Some of the "features" look like implementation details so you might
want to consider from a users' pov

Bug#1072715: make it easier to change autopkgtest backends

[Richard Lewis]

Package: sbuild
Version: 0.85.0
Severity: wishlist
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

sbuild is really great. I have a small feature request to make it easier to 
navigate the autopkgtest options:

In sbuild.conf i use

  $autopkgtest_root_args = '';
$autopkgtest_opts = [ '--', 'schroot', '%r-%a-sbuild' ];

but sometimes i need to lxc because schroot isnt enough of a container, or i 
need to match what happens on salsa
And now i need to use sudo, i have to remember to uncomment the following two 
lines

$autopkgtest_root_args = 'sudo';
$autopkgtest_opts = [ '--', 'lxc', 'autopkgtest-%r' ];

and then recomment after...  -- I know i can pass these on the command line, 
but i can never remember the syntax for each.

Could these variables be set via via hashes, so i could easily choose at 
run-time whether to use lxc or schroot
(or unshare etc):

I was thinking you could support a syntax like:

  $autopkgtest_backend="schroot" # default backend

# bash of backend => "value to use"
$autopkgtest_root_args_hash = { "schroot" => "", "lxc" => "sudo", 
"unshare"=>"run0" };

# bash of backend => [args,to,use]
  $autopkgtest_opts_hash = {
"lxc" => [ '--', 'lxc', 'autopkgtest-%r' ], 
"schroot" => [ '--', 'schroot', '%r-%a-sbuild' ],
}

and then doing --autopkgtests-backend=X would simply do call

$autopkgtest_root_args=$autopkgtest_root_args_hash[X];
$autopkgtest_opts=$autopkgtest_opts_args_hash[X];

would that be possible?

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

I'm going to need a spot of help with this.

I have Chromium running under GDB, with surprisingly low overhead (I can
browse like normal if I drop the --single-process flag). As far as I
could find, the "trap invalid opcode" error reported in syslog is
synonymous with a SIGILL, so I set "handle SIGILL stop pass".
Unfortunately, the trap errors continue to occur without GDB stopping
execution.

Do you know how to set this up to get to a backtrace? Maybe a way of
disabling the signal/crash handler?

Bug#241787: options to seperate hosts and for log compaction would both be nice

[Richard Lewis]

On Sun, 12 May 2024 17:01:36 +0100 Richard Lewis
 wrote:
> > This bug is nearly 20 years old. (It is a shame no-one replied - the links
> > no longer work and there is not enough info recorded to action)
> >
> > Unless anyone is watching and can proivde more info about what the issue
> > is/was then i suggest we close it.

A year later: closing.

 logcheck can send reports as gzip'd attachments so perhaps it was even
 fixed sometime in the last 20 years.

Bug#654557: logcheck-database: pure-ftpd rules need update

[Richard Lewis]

On Sat, 1 Jun 2024 at 14:21, Kiss Gabor (Bitman)  wrote:
>
> On Sat, 1 Jun 2024, Richard Lewis wrote:
>
> > > does not cover log entry
> > >
> > > Jan  4 07:23:42 gatling pure-ftpd: (?@203.158.197.21) [INFO] Logout.
> > >
> > > The problem is with ? before @.
> >
> > It's a shame no-one replied to this bug from 2012
> > Is there still interest in adding this rule, and is the above still valid?
>
> Dear Richard,
>
> I was not waiting paralyzed till now. :-)
> I've created a local rule to solve the problem.
>
> > is the above message really harmless? it the bit before the @ is meant
> > to be a username then it looks like something fishy is going on and
> > this message should not be filtered?
>
> AFAIK "?" stands for the username if the session is terminated
> before logging in.
>
> May 26 06:49:14 gatling pure-ftpd: (?@152.32.206.247) [INFO] Logout.
> May 26 06:49:14 gatling pure-ftpd: (?@152.32.206.247) [INFO] New connection 
> from 152.32.206.247
> May 26 06:49:33 gatling pure-ftpd: (?@152.32.206.247) [INFO] Logout.
> May 26 06:49:33 gatling pure-ftpd: (?@152.32.206.247) [INFO] New connection 
> from 152.32.206.247
> May 26 06:49:33 gatling pure-ftpd: (?@152.32.206.247) [INFO] Anonymous user 
> logged in
> May 26 06:49:33 gatling pure-ftpd: (ftp@152.32.206.247) [INFO] Logout.
>
> I think this is quite uninteresting. But it's up to you.

thank-you - i agree, we should add this to the rules.

I also see that there is some other rules in pureftp in both
ignore.d.server and ignore.d.paranoid. Merging everything into
ignore.d.server my candidate rules are:

([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([?_.[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\]
New connection from [._[:alnum:]-]+$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([?_.[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\]
[_.[:alnum:]-]+ is now logged in$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\]
Can't change directory to .+: (No such file or|Not a) directory$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\]
Timeout - try typing a little faster next time$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\]
Timeout \(no new data for [0-9]+ seconds\)$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([?_.[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\]
Logout\.$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[NOTICE\]
.+ (up|down)loaded  \([0-9]+ bytes, [0-9.]+KB/sec\)$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[NOTICE\]
File successfully renamed or moved: \[.+\]->\[.+\]$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[NOTICE\]
Deleted .+$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\]
Timeout$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[ERROR\]
Can't open .+: No such file or directory$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \([_.[:alnum:]-]+@[._[:alnum:]-]+\) \[ERROR\]
Can't remove directory: No such file or directory$
([[:alpha:]]{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+
pure-ftpd(\[[0-9]+\])?: \(\?@[._[:alnum:]-]+\) \[DEBUG\] This is a
private system - No anonymous login$
---
I have some followups:


1. whether all rules should allow a ?
I see that the first 2 rules already allowed a ? -- should all the
other rules should allow a ? or just the login/logout one? (do you get
a "?" for all anonymous users for example?)

2. lack of pids
The rules all start

  pure-ftpd: ...

do you really not see a pid after the "pure-ftpd"? this might be a
syslog vs systemd thing but proabbly we should allow an optional pid?
(if you did "journalctl -t pure-ftpd" you would see a pid i think, so
we should add that as an optional group(?)


3. The last rule was
 ... pure-ftpd: PAM-listfile: Refused user [._[:alnum:]-]+ for service
pure-ftpd$

I assume this a) comes from PAM b) isnt produced any more?

Bug#651319: ignore.d.server/nagios: SERVICE FLAPPING line doesn't allow whitespace

[Richard Lewis]

On Wed, 07 Dec 2011 09:39:55 -0800 andrew bezella  wrote:
> Package: logcheck-database
> Version: 1.3.13
> Severity: minor
>
> in most cases whitespace is allowed in SERVICE names, but for the
> SERVICE FLAPPING ALERT it is not.  using the cases where
> whitespace is allowed as a template, i made the following change:

Is there still a need for this rule in 2024, and is there still
interest in adding it to logcheck?

The proposed change was to add

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ nagios(2|3)?: SERVICE
FLAPPING ALERT: [._[:alnum:]-]+;[^;]+;(STARTED|STOPPED); Service
appears to have (started|stopped) flapping \([[:digit:].]+% change
(<|>=?) [.[:digit:]]+% threshold\)$

however, i think this needs an update:
- missing a pid
- the package is nagios4 now, so presumably the "(2|3)?" needs amending

If an updated rule is provided we can consider adding it, but i
suspect we may end up closing this bug

Bug#591757: logcheck-database: please update ignore rules for nagios

[Richard Lewis]

On Thu, 05 Aug 2010 11:28:16 +0200 Albert Dengg  wrote:

> please update the ignore rules for nagios:
> nagios (at least nagios3) will write two lines for each passive
> service check that it resives through nsca:
>  nagios3: EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;...
>  nagios3: PASSIVE SERVICE CHECK: ...
>
> the first one is already ignored, but the last one triggers an email
> every time logcheck runs if there were any passive service check results.
>
> at least in my enviroment that makes it unusable because in my enviroment it
> is normal that i recive serveral passive service results
> (it would be more alarming if they are not there actually...)
>
> so i wrote a simple rule to ignore them (see patch)

The provided file proposed the following rule:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ nagios(2|3)?: PASSIVE SERVICE
CHECK: [._[:alnum:]-]+;.*$

Is there still nned and interest in adding this - i think it needs
some updating in 2024, for example:
- missing a PID,
- unclear whether the (2|3)? is still needed? the package seems to be
nagios4 now
- it looks quite broad(?)

so i suspect the need for this rule has passed?

Bug#590677: [logcheck-database] additional rules for nagios/radius

[Richard Lewis]

On Wed, 28 Jul 2010 13:52:44 +0200 Hendrik Jaeger  wrote:
> Package: logcheck-database
> Severity: wishlist
> Tags: patch
>
>
> Hi,
>
> check_radius output filter:
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ check_radius: rc_avpair_gen:
> received VSA attribute with unknown Vendor-Id [[:digit:]]+$


A shame no-one replied - 14 years later, is this still valid? it looks
like it is missing a PID to me

If there is still interest in adding this then please provide an updated ruleset

Bug#690607: logcheck-database: consider to add a line to ignore.d.server/cyrus-imapd

[Richard Lewis]

On Tue, 16 Oct 2012 03:04:36 +0200 Sebastian Steinhuber
 wrote:
> Package: logcheck-database
> Version: 1.3.15
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
> to drop messages of the form:
>
> Oct 15 21:01:22 dds cyrus/cyr_expire[26497]: DIGEST-MD5 common mech free
>
> I added a line (#13) to ignore.d.server/cyrus-imapd:
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ cyrus/[a-zA-Z0-9_]+\[[0-9]+\]:
> DIGEST-MD5 common mech free$
>

It's a shame no-one replied to this bug from 2012 - more than 10 years
later, is this rule still needed, and is there still interest in
adding it to logcheck?

i wonder if this message is  produced any more, given it refers to MD5
(and why do people add such unintelligible log messages to their
code?)
we'd need an updated ruleset to add it to logcheck

Bug#764062: logcheck-database: does not filter amavis CLEAN messages

[Richard Lewis]

On Fri, 17 Oct 2014 00:57:07 +0200 =?UTF-8?B?SsOpcsO0bWUgRHJvdWV0?=
 wrote:

> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ amavis\[[[:digit:]]+\]:
> \([-[:digit:]]+\) Passed (CLEAN|SPAM(MY)?)( {RelayedInbound})?,( LOCAL)?(
> \[(IPv6:)?[[:xdigit:].:]{3,39}\](:[[:xdigit:]]{0,5})?){0,2} <[^>]*> ->
> <[^>]*>(,<[^>]*>)*,( quarantine:
> ([[:alnum:]]/)?spam-[-+[:alnum:]]+(\.gz)?,)?( Queue-ID: [[:xdigit:]]*,)?(
> Message-ID: <[^>]+>( \((added by[^)]+|sfid-[_[:xdigit:]]+)\))?,)?(
> Resent-Message-ID: <[^>]+>,)? mail_id: [-+_[:alnum:]]+, Hits:
> (-?[.[:digit:]]*)+, size: [[:xdigit:]]+, queued_as: [[:xdigit:]]+( OK
> id=[-[:alnum:]]+)?, [[:digit:]]+ ms$

It's a shame no-one replied to this bug from 2014 - 10 years later, is
it still valid, and is there still interest in adding it to logcheck?

if so, we'd need an updated ruleset / confirmation nothing has changed
(isnt it "amavisd-new" nowadays?)

Bug#689418: logcheck-database: refine sendmail STARTTLS rule

[Richard Lewis]

On Tue, 02 Oct 2012 14:28:24 +0200

> With sendmail, self-signed certificates trigger a warning like:
>
> | Oct  2 13:02:07 hostname sm-mta[24652]: STARTTLS=client, 
> relay=host.example., version=TLSv1/SSLv3, verify=FAIL, 
> cipher=DHE-RSA-AES256-SHA, bits=256/256
>
> There is a logcheck rule for this case (which can be safely ignored),
> however it states:
>
> | ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (sendmail|sm-(mta|msp|que))\[[0-9]+\]: 
> STARTTLS=(server|client), .* verify=(OK|NO)
>
> This should be changed into:
>
> | ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (sendmail|sm-(mta|msp|que))\[[0-9]+\]: 
> STARTTLS=(server|client), .* verify=(OK|NO|FAIL)

It's a shame no-one replied since 2012,

I wonder if this rule is still valid, and more broadly whether it is
even a good idea - if certificate verification fails you'd want to
know, so ignoring all FAIL messages seems too much?

Is there still interest in adding this to logcheck? we'd need an
updated ruleset to do so

Bug#632825: logcheck: New ignore rule for arpwatch

[Richard Lewis]

On Wed, 06 Jul 2011 10:22:21 +0200 Wojciech Nizinski  wrote:


> Please add following ignore rule for arpwatch:
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ arpwatch: short \(want 42\)$

It's a shame no-one replied since 2011,
Is there still interest in adding this rule to logcheck-database?

it looks like it needs updating, eg to add a PID after 'arpwatch', and
we'd need an updated rule to add it

Bug#778905: logcheck: logging changes in spamd

[Richard Lewis]

control: tags  -1 + moreinfo
thanks

On Sat, 21 Feb 2015 14:57:15 + Andrew Gallagher  wrote:

> spamd no longer suffixes "(closed before headers)" with "at /usr/sbin/spamd 
> line N"
>
> Updated rule attached. This may also apply to other errors that I haven't 
> been able to test yet.

It's a shame no-one replied to this bug fro 2015

The attached file contains:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ spamd\[[0-9]+\]:( spamd:)? bad
protocol: header error: \(closed before headers\)( at /usr/sbin/spamd
line 2001.)?$

This looks problematic because
- if the suffix is no longer produced the rule should not include it as optional
- why is 2001 hardcoded?

If there is still interest in adding/updating rules we'd need an
update to confirm what the rules should look like in 2024,

Bug#740203: logcheck-databse: proposed ignore rules for hostapd

[Richard Lewis]

control: tags -1 + moreinfo
thanks

On Wed, 26 Feb 2014 22:21:18 +0100 Gabriel Niebler
 wrote:

> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ hostapd: [[:alnum:]]+: STA 
> ([0-9a-f]{2}:){5}[0-9a-f]{2} IEEE 802\.11: authenticated$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ hostapd: [[:alnum:]]+: STA 
> ([0-9a-f]{2}:){5}[0-9a-f]{2} IEEE 802\.11: associated \(aid [[:digit:]]\)$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ hostapd: [[:alnum:]]+: STA 
> ([0-9a-f]{2}:){5}[0-9a-f]{2} IEEE 802\.11: deauthenticated due to local 
> deauth request$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ hostapd: [[:alnum:]]+: STA 
> ([0-9a-f]{2}:){5}[0-9a-f]{2} WPA: pairwise key handshake completed \(RSN\)$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ hostapd: [[:alnum:]]+: STA 
> ([0-9a-f]{2}:){5}[0-9a-f]{2} WPA: group key handshake completed \(RSN\)$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ hostapd: [[:alnum:]]+: STA 
> ([0-9a-f]{2}:){5}[0-9a-f]{2} WPA: received EAPOL-Key 2/2 Group with 
> unexpected replay counter$


It's a shame no-one replied to this bug from 2014,

Is there still interest in adding these to logcheck-database? I think
they need an update eg to add a PID after 'hostapd', and i wonder if
they are sill produced or if other changes are needed in 2024?

Bug#686144: logcheck: ignore.d.server/imapproxy regex for LOGIN and LOGOUT lines from syslog wrong

[Richard Lewis]

control: tags -1 + moreinfo

On Wed, 29 Aug 2012 07:03:36 +0200 Sven Fischer
 wrote:
> Package: logcheck
> Version: 1.3.13
> Severity: normal
>
> In ignore.d.server/imapproxy the first two lines (LOGIN and LOGOUT) for the 
> regex contain double quotes. These are too much, hence the regex does not 
> work when used with syslog.
> Leaving them out, solves the problem.
>
> example syslog entries for imapproxyd, which should match with the logcheck 
> rules for imapproxy:
> Aug 29 00:10:23 vserver1901 in.imapproxyd[22478]: LOGIN: 'i...@linux44tw.de' 
> (127.0.0.1:41773) on existing sd [10]
> Aug 29 00:10:24 vserver1901 in.imapproxyd[22478]: LOGOUT: 'i...@linux44tw.de' 
> from server sd [10]
>
> Original lines:
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.imapproxyd\[[0-9]+\]: LOGOUT: 
> '"[_[:alnum:]-]+(@[-_.[:alnum:]]+)?"' from server sd \[[0-9]+\]$
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.imapproxyd\[[0-9]+\]: LOGIN: 
> '"[_[:alnum:]-]+(@[-_.[:alnum:]]+)?"' 
> \([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]+\) on (existing|new) 
> sd \[[0-9]+\]$
>
> lines adjusted to work with the syslog entries from imapproxy:
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.imapproxyd\[[0-9]+\]: LOGOUT: 
> '[_[:alnum:]-]+(@[-_.[:alnum:]]+)?' from server sd \[[0-9]+\]$
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.imapproxyd\[[0-9]+\]: LOGIN: 
> '[_[:alnum:]-]+(@[-_.[:alnum:]]+)?' 
> \([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]+\) on (existing|new) 
> sd \[[0-9]+\]$
>
> Two quotation marks too much in each line. That's it.

It's a shame no-one replied to this bug report from 2012 - i wonder if
it is still valid?

Bug#654557: logcheck-database: pure-ftpd rules need update

[Richard Lewis]

control: tags -1 + moreinfo
thanks

On Wed, 04 Jan 2012 09:58:11 +0100 Gabor Kiss  wrote:

> /etc/logcheck/ignore.d.server/pure-ftpd rule
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ pure-ftpd: 
> \([._[:alnum:]-]+@[._[:alnum:]-]+\) \[INFO\] Logout\.$
>
> does not cover log entry
>
> Jan  4 07:23:42 gatling pure-ftpd: (?@203.158.197.21) [INFO] Logout.
>
> The problem is with ? before @.

It's a shame no-one replied to this bug from 2012
Is there still interest in adding this rule, and is the above still valid?

is the above message really harmless? it the bit before the @ is meant
to be a username then it looks like something fishy is going on and
this message should not be filtered?

Bug#652537: Please add rule for inetutils-syslogd

[Richard Lewis]

control: tags -1 moreinfo

On Sun, 18 Dec 2011 11:11:13 + debian-b...@nospam.pz.podzone.net wrote:
> Package: logcheck
> Version: 1.2.69
>
> The inetutils-syslogd (2:1.5.dfsg.1-9) package provides a system
> logging daemon.  syslogd periodically logs the following message:
>
> Dec 17 00:29:11 host syslogd (GNU inetutils 1.5): restart
>
> The following logcheck rulefile works to filter the messages from the
> "System Events" email:
>
> # cat inetutils-syslogd
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslogd \(GNU inetutils [1-9]\.[0-9]+\): 
> restart$
>
> This bug report is for logcheck 1.2.69 but I have looked at the
> logcheck package files in wheezy (1.3.14) and it appears
> inetutils-syslogd remains unaccounted for (although note that
> inetutils-syslogd is now at 2:1.8-5).
>

It's a shame no-one replied to this bug from 2011!

The above comment suggests the rule provided is no longer valid as the
version is now different
Also, we dont usually add rules for starup messages - if the above is
only produced on startup we wouldnt add it anyway

Is there still interest in adding rules for inetutils-syslogd to
logcheck? if so, we'd need an updated set of rules, otherwise we will
have to close this bug

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

On Fri, 2024 May 31 21:49-04:00, Andres Salomon wrote:
> Oh! Apparently my info is outdated. According to 
> , this was fixed back in August. It does 
> indeed look like
>  
> has the dbgsym packages for .141.

Thanks for the pointer. I did not know about debian-security-debug, as
the Debian wiki pages make no mention of it.

I've installed .141 and the dbgsym package, and confirmed that at
least the tab crash still occurs. Will try to get some useful
telemetry out of this.


--Daniel

Bug#909036: logcheck: Please update ignore rules for named GeoIP (after upgrade to Strech)

[Richard Lewis]

control: tags -1 + confirmed

On Mon, 17 Sep 2018 20:48:12 +0200 mi te  wrote:
> Package: logcheck
> Version: 1.3.18
> Severity: normal
>
> Dear Maintainer,
>
> After upgrade to Stretch, get a notification from logcheck every time after 
> BIND is restarted for logrotate.
> They should be added to the ignore.d.server/bind file, IMHO.
>
> Sep 17 00:06:02 servername named[1166]: initializing GeoIP Country (IPv4) 
> (type 1) DB
> Sep 17 00:06:02 servername named[1166]: GEO-106FREE 20170512 Bu
> Sep 17 00:06:02 servername named[1166]: initializing GeoIP Country (IPv6) 
> (type 12) DB
> Sep 17 00:06:02 servername named[1166]: GEO-106FREE 20170512 Bu
> Sep 17 00:06:02 servername named[1166]: initializing GeoIP City (IPv4) (type 
> 2) DB
> Sep 17 00:06:02 servername named[1166]: GEO-106FREE 20170512 Bu
> Sep 17 00:06:02 servername named[1166]: GeoIP City (IPv6) (type 30) DB not 
> available
> Sep 17 00:06:02 servername named[1166]: GeoIP City (IPv6) (type 31) DB not 
> available
> Sep 17 00:06:02 servername named[1166]: GeoIP Region (type 3) DB not available
> Sep 17 00:06:02 servername named[1166]: GeoIP Region (type 7) DB not available
> Sep 17 00:06:02 servername named[1166]: GeoIP ISP (type 4) DB not available
> Sep 17 00:06:02 servername named[1166]: GeoIP Org (type 5) DB not available
> Sep 17 00:06:02 servername named[1166]: initializing GeoIP AS (type 9) DB
> Sep 17 00:06:02 servername named[1166]: GEO-106FREE 20170512 Bu
> Sep 17 00:06:02 servername named[1166]: GeoIP Domain (type 11) DB not 
> available
> Sep 17 00:06:02 servername named[1166]: GeoIP NetSpeed (type 10) DB not 
> available
> Sep 17 00:06:02 servername named[1166]: configuring command channel from 
> '/etc/bind/rndc.key'

It;s a shame no-one replied sooner, and it seems this bug is (partly)
valid still. I think the messages have changed and on daily restart my
candidate rules relating to GeoIP are

$X: looking for GeoIP2 databases in '/usr/share/GeoIP'$
$X:configuring command channel from '/etc/bind/rndc\.key'$

where $X is the usual prefix for named

(this is with a default-ish config -- i do vaguely recall the the
above lines more complex  some time ago, but i think the above
suffices in 2024)

Bug#547774: dovecot-related rules against logcheck

[Richard Lewis]

On Thu, 30 May 2024 at 20:43, Boyd Stephen Smith Jr.
 wrote:
>
> On Thursday, May 30, 2024 12:37:49 PM CDT Richard Lewis wrote:
> > Is there still interest in updating rules for dovecot?
>
> Best I can volunteer is my current dovecot-local that is in active use.
> (Attached.)

Thanks, i will take a look

Bug#691258: Missing / in RE for "reducing the advertised EDNS UDP packet size"

[Richard Lewis]

On Tue, 23 Oct 2012 17:55:06 +0200 =?utf-8?B?TG/Dr2M=?= Minier
 wrote:
> Package: logcheck
> Version: 1.3.15
> Severity: minor
> Tags: patch
>
> Hi,
>
> Got this log from time to time in System Events:
> Oct 23 13:48:16 pig2 named[28880]: success resolving 
> '26.0/25.218.183.203.in-addr.arpa/PTR' (in '0/25.218.183.203.in-addr.arpa'?) 
> after reducing the advertised EDNS UDP packet size to 512 octets
>
> Changing the regexp for the "(in '...'?)" part from:
> ^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]-]+ named\[[0-9]+\]: success 
> resolving '[^[:space:]]+' \(in '[.[:alnum:]-]+'\?\) after (disabling 
> EDNS|reducing the advertised EDNS UDP packet size to 512 octets)$
> to:
> ^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]-]+ named\[[0-9]+\]: success 
> resolving '[^[:space:]]+' \(in '[/.[:alnum:]-]+'\?\) after (disabling 
> EDNS|reducing the advertised EDNS UDP packet size to 512 octets)$
>


It's a shame no-one replied to this bug from 2012.

A lot has changed in that time, and eg EDNS is now more common- i do
remember seeing messages like this in the past, and adding locla
rules, but i  unless i am missing something i dont see these
messages at all in journal or bind.log today, so perhaps this bug can be closed.

 (i may well be missing something  - if these are in fact common then
we should definitely filter them as there's not much you can do!)

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

On Fri, 2024 May 31 18:36-04:00, Andres Salomon wrote:
>
> I'm going from memory here, but I believe the dak installation on 
> security.debian.org doesn't keep dbgsym packages for historical reasons. 
> Thus, they're only available once chromium gets moved to 
> stable-proposed-updates. https://tracker.debian.org/pkg/chromium shows 
> .60 as being the last one in stable-p-u. At some point in the next week 
> or two, someone from the release team will likely accept the newer 
> chromium packages into stable-p-u, at which point the dbgsym packages 
> for .141 (or whatever the latest version is) will be available.

Eeegh, not a great state of affairs for a package that revs this often.

> It sucks, but it is what it is. You could either spend a bunch of time 
> building chromium for the dbgsym packages, or I could put my local build 
> of .141 online w/ dbgsym packages for you to try out (assuming amd64?), 
> or you could downgrade to .60 and use those dbgsym packages.

If it's not too much trouble to put up that .141 package (and the
problem still persists in that version), I'll gladly make use of it.

> Yes, just running 'chromium -g' will launch it inside gdb; you may have 
> to manually type 'run' to start it inside gdb, I forget.  But then 
> you'll get a backtrace (or you can ctrl-c and run 'bt', if it's a 
> deadlock or something). I haven't bothered w/ core dumps of chromium 
> before, so I can't speak to that.

Understood. The system in question is a bit tight on memory, so
hopefully it won't fall over with Chromium under GDB.


--Daniel

Bug#687990: logcheck-database: bind: "updating zone...PTR" and "signer...approved"

[Richard Lewis]

On Tue, 18 Sep 2012 06:00:06 +0200 Paul Muster  wrote:
> Update:
>
> > (1) please change
> >
> > ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ named\[[[:digit:]]+\]: client
> > [.:[:xdigit:]]+#[[:digit:]]+: updating zone '[-._[:alnum:]]+/IN':
> > (adding an RR|deleting rrset) at '[._[:alnum:]-]+' A$
> >
> > to
> >
> > ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ named\[[[:digit:]]+\]: client
> > [.:[:xdigit:]]+#[[:digit:]]+: updating zone '[-._[:alnum:]]+/IN':
> > (adding an RR|deleting rrset|deleting an RR) at '[._[:alnum:]-]+' 
> > (A|PTR|TXT)$


It's a shame no-one replied to this bug from 2012.

I suspect these no longer match anything, but more broadly: I;m not
sure logcheck should be filtering messages related to zone transfers
by default: that seems like quite a niche/advanced/worrying situation
-- for most people using bind i think you'd want to know if someone
was transferring or updating your zones - i certainly would not want
these filtered.

Nothing to stop people with advanced configurations adding local rules
of course, but the defaults should be conservative here. So am tempted
to close/wontfix this one.

However, if anyone is watching this bug and takes a diffferent view
please reply
as this is worth a discussion (and im going through bind rules currently)

Bug#590675: [logcheck-database] additional rules for bind

[Richard Lewis]

On Wed, 28 Jul 2010 13:49:43 +0200 Hendrik Jaeger  wrote:
> Package: logcheck-database
> Severity: wishlist
> Tags: patch
>
> Hi,
>
> We have some additional rules for bind:
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ named\[[0-9]+\]:
> (general: )?(info: )?received control channel command 'stats'$ ^\w{3}
> [ :0-9]{11} [._[:alnum:]-]+ named\[[0-9]+\]:
> (general: )?(info: )?dumpstats complete$

It's a shame no-one replied sooner to this bug from 2010 -- I think
these are no longer produced by bind in 2024 (i do vaguely remember
something like this a long time ago, but i dont see these now)

so we should probably close this bug

(I am reviewing bind rules and the current candidates that look close
is something like

$X: received control channel command '(reload|recursing|secroots
-|managed-keys status)'$

where $X is the usual prefix

>
> HTH
>
> Hendrik
>
> --
> Hendrik Jaeger
> Linux Systemadministrator
>
> Init Seven AG
> Elias-Canetti-Strasse 7
> CH-8050 Zürich
> phone: +41 44 315 44 00
> fax: +41 44 315 44 01
> http://www.init7.net/
>

Bug#1072317: Redundant build when making packed_resources

[Daniel Richard G.]

Package: chromium
Version: 125.0.6422.141-1
Severity: minor

This is something I've noticed in the course of the build that has been
annoying me for some time, and I thought I'd write it up.

Here is an excerpt from the build log which illustrates the problem:

[...]
[61738/61742] AR obj/content/web_test/libweb_test_renderer.a
[61739/61742] AR obj/content/web_test/libweb_test_browser.a
[61740/61742] AR obj/content/shell/libcontent_shell_app.a
[61741/61742] LINK ./content_shell
[61742/61742] LINK ./chrome
cp out/Release/chrome out/Release/chromium
cp out/Release/content_shell out/Release/chromium-shell
[...]
   debian/rules override_dh_auto_build-indep
make[1]: Entering directory '/tmp/chromium-125.0.6422.141'
gn gen out/Release --args="clang_use_chrome_plugins=false ..."
Done. Made 20173 targets from 3449 files in 10398ms
ninja -j8 -C out/Release packed_resources
ninja: Entering directory `out/Release'
[1/30013] CXX 
obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/file_util_posix.o
[2/30013] CXX 
obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/time_override.o
[3/30013] CXX 
obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/stack_trace_linux.o
[...]

It's not clear why, but the "gn gen" operation in the
override_dh_auto_build-indep target renders a significant chunk of the
existing build tree stale, and the packed_resources build then has to
recompile a bunch of things that are distant dependencies of the
requested resource files.

I can't say at what version this started happening, but I do seem to
recall at one point the packed_resources build needing only a three-
digit number of steps.

Would it be reasonable to do something like

 override_dh_auto_build-indep:
-gn gen out/Release --args="$(defines)"
+test -f out/Release/build.ninja || gn gen out/Release 
--args="$(defines)"
 ninja -j$(njobs) -C out/Release packed_resources

so that it doesn't run "gn gen" again, if not necessary?


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

Sigh, spoke too soon.

Chromium still crashes in both modes (tab and browser) even without
Firefox running, but much less frequently. I had a good half-hour
without crashes after closing Firefox, enough to lead me to think that
was the cause.

At this point, we're probably better off waiting to see if .141
still has the issue. But is there a reason why that -dbgsym package
isn't there?


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

I believe I've found a correlation: The crashes seem to have started
with an instance of firefox-esr (115.11.0esr-1~deb12u1) that I was
running on the side, since earlier today. Once I closed Firefox, the
crashiness went away, completely.

(This is on the same laptop that needs --use-gl=egl to avoid visual
artifacts, so that might have something to do with this)

On Fri, 2024 May 31 15:27-04:00, Andres Salomon wrote:
>
> Interesting. Any chance of a backtrace (with the chromium-dbgsym 
> package)? I'm wondering if some (bundled) third party lib has started 
> requiring newer cpu extensions or something.

I'm happy to provide this, but two questions:

1. In http://debug.mirrors.debian.org/debian-debug/pool/main/c/chromium/
   as well as https://deb.debian.org/debian-debug/pool/main/c/chromium/,
   I don't see any packages with a matching version string of
   "125.0.6422.112-1~deb12u1" (and .141 isn't there yet). Am I missing
   something?

2. To get the stack trace, is the right way just running the whole
   thing in GDB, using "chromium -g"? Or do you set it up to make a
   core dump? (Sure would be nice to have an Apport-like after-the-fact
   workflow for this)


--Daniel

Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

Package: chromium
Version: 125.0.6422.112-1~deb12u1
Severity: important

Recently, I have been observing crashes of individual tabs, and even
of the entire browser, when navigating some Web pages. The crashed
tabs correlate with the following syslog messages (multiple instances
listed below):

2024-05-31T12:42:35.334876-04:00 runabout kernel: [1324259.940186] traps: 
Compositor[125485] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded490 error:0 
in chromium[55a9c7e22000+b13d000]
2024-05-31T12:57:20.174268-04:00 runabout kernel: [1325144.782743] traps: 
Compositor[125761] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded1e0 error:0 
in chromium[55a9c7e22000+b13d000]
2024-05-31T13:24:20.059327-04:00 runabout kernel: [1326764.664063] traps: 
Compositor[126515] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ed1e0 error:0 
in chromium[55daa7faa000+b13d000]
2024-05-31T13:55:26.767783-04:00 runabout kernel: [1328631.258090] traps: 
Compositor[126307] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ecfb0 error:0 
in chromium[55daa7faa000+b13d000]

The whole-browser crash occurs with no unusual messages to syslog or
~/.xsession-errors, strangely enough.

And even stranger, only today (May 31) have I started observing these
crashes. This particular version has been installed and running fine
since May 23, and now it's crashing left and right. /var/log/dpkg.log
shows no new package installs since the 25th, and I haven't futzed with
any configurations for at least that long.

Since the error relates to an invalid opcode, I'll include some details
about the CPU:

vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz
stepping: 6
microcode   : 0xc7
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow dtherm


--Daniel

Bug#1054393: dns-root-data: New IPs for b.root-servers-net 2023-11-27

[Richard Hector]

So was it decided not to fix this in stable (bookworm)?

That's a pity.

Richard

Bug#1070482: systemd: tmpfiles.d not cleaning /var/tmp by default

[Richard Lewis]

Luca Boccassi  writes:

> Here's two paragraphs, one for each change, for the release notes:

- More context and explanation would be helpful - suggestions below,

- Based on the discussion on d-devel, the tmpfs change is much less
   controversial and so should be lower down.

- how do we describe the previous postition /tmp was: a regular
  directory? a partition?

- some obvious questions need answering:

  * if i have a file in /tmp (and disable the other change) what
actually happens to that file? is it moved "into" the tmpfs or is it
hidden by the tmpfs?

  * if i have /tmp as a 2TB separate disk partition do i just lose that
 space? or does tmpfs immediately gobble up all my available RAM?

  * what happens to my files if i run out of memory because someone
wrote a 500GB file to /var/tmp?

- you could do more to explain the benefits and rationale here - tmpfs
   is (i assume) faster?

- sudo is not how most(?) debian users do things
- tmpfiles.d should be systemd-tmpfiles(1) i think?
- using names like /etc/tmpfiles.d/tmp.conf might clobber existing files?
- highly optimistic about how well people know systemd!

=
This needs an edit/cut, but:

Debian has made two major changes for new installations to the temporary
directories (/tmp and /var/tmp). Because there is a small risk of data
loss, these changes have not been made for upgrades. You may wish to
adopt the new defaults as explained below.

On new installations, systemd-tmpfiles(1) will now delete files in /tmp
and /var/tmp while the system is running. Previously, files in those
directories were only deleted on reboot, but now files in /tmp will be
deleted after 10 days, and files in /var/tmp after 30 days.  [is this
really the defualt it seems very short?] If you adopt this change you
can tell systemd-tmpfiles not to delete individual files by making a
file in /etc/tmpfiles.d with lines such as

  x /var/tmp/my precious file.pdf
  x /tmp/foo

Please see systemd-tmpfiles(1) for more information. On new
installations, the previous behaviour can be restored by creating a file
tmp.conf in /etc/tmpfiles.d containing 'D /tmp 1777' [are you sure this is the 
correct syntax???]

In addition, on new installations, the /tmp/ directory is now stored in
memory, using a tmpfs(LINK). This should make applications that use
temporary files faster. You can adopt the new default by running
'systemctl unmask tmp.mount' as root [i assume?]. (If you created /tmp
as a separate partition you may want to reclaim the space using lvm or
sfdisk?).

The new behaviour allocates x% of memory to the tmpfs but you can change
this by [how?]. If you have large files in /tmp and you run out of
memory then [what happens?]. On new installations you can make /tmp a
regular directory by running 'systemctl mask tmp.mount' as root [i
assume?].

These changes have been made to align Debian with other distributions,
and you should adapt any local programs that store data in /tmp or
/var/tmp for long periods to use alternative locations, such as ~/tmp/
or [exclude files from deletion as explained above?]. [i think there
are more points in the d-devel discussion that need making here]

===

Bug#778903: logcheck: saslauthd logging has changed

[Richard Lewis]

On Sat, 21 Feb 2015 14:53:21 + Andrew Gallagher  wrote:

> New versions of saslauthd say "pam_unix(smtp:auth)" instead of "(pam_unix)".
> New rule is:
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ saslauthd\[[[:digit:]]+\]: 
> pam_unix\(smtp:auth\) authentication failure; logname= uid=0 euid=0 tty= 
> ruser= rhost=( [[:space:]]*user=[-._[:alnum:]]+)?$

Is this still the case in 2024?

(This looks like possibly also the solution to bug 690145, which i
will try and merge with this)

Bug#765944: logcheck-database: improved openvpn rules

[Richard Lewis]

On Sun, 19 Oct 2014 14:06:02 +0100 Peter Wyss  wrote:
> Package: logcheck-database

> The logcheck ignore.d.server rules for openvpn need some adjustments.
>
> The following 2 entries need to be adjusted to include [AF_INET]:
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ 
> (openvpn|ovpn-[._[:alnum:]-]+)\[[[:digit:]]+\]:( 
> ([-_.@[:alnum:]]+/)?[.[:digit:]]{7,15}:[[:digit:]]{2,5})? TLS: Initial packet 
> from (\[AF_INET\])?[.[:digit:]]{7,15}:[[:digit:]]+, sid=[[:xdigit:]]{8} 
> [[:xdigit:]]{8}$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ 
> (openvpn|ovpn-[._[:alnum:]-]+)\[[[:digit:]]+\]:(( 
> ([-_.@[:alnum:]]+/)?[.[:digit:]]{7,15}:[[:digit:]]{2,5})?( 
> \[[-._[:alnum:]]+\])?)? Peer Connection Initiated with 
> (\[AF_INET\])?[[:digit:].]{7,15}:[[:digit:]]+$
>
> The following 2 entries are missing:
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ 
> (openvpn|ovpn-[._[:alnum:]-]+)\[[[:digit:]]+\]:( 
> ([-_.@[:alnum:]]+/)?[.[:digit:]]{7,15}:[[:digit:]]{2,5})? MULTI_sva: pool 
> returned IPv4=[.[:digit:]]{7,15}, IPv6=[[:xdigit:].:]{3,39}$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ 
> (openvpn|ovpn-[._[:alnum:]-]+)\[[[:digit:]]+\]:( 
> ([-_.@[:alnum:]]+/)?[.[:digit:]]{7,15}:[[:digit:]]{2,5})? 
> send_push_reply\(\): safe_cap=[[:digit:]]+$

Hi,
it's a shame no-one replied since 2014 - let's change that.

Is this bug still valid - i imagine messages will have moved on since 2014?

Bug#693183: Please include ignore.d.server rules for DMA

[Richard Lewis]

On Wed, 14 Nov 2012 03:50:07 +0100 Carlos Alberto Lopez Perez
 wrote:
> Package: logcheck-database

> Hello,
>
> After deploying DMA, I found that logcheck is not filtering the typical
> notification messages of mail delivery that any mailer daemon generates.
>

> I successfully filtered all this notification messages with the following 
> rules
>
> # cat /etc/logcheck/ignore.d.server/dma
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ dma\[[0-f.]+\]: new mail from 
> user=[[:alpha:]]+ uid=[0-9]+ envelope_from=<[@._[:alnum:]-]+>$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ dma\[[0-f.]+\]: mail 
> to=<[@._[:alnum:]-]+> queued as [0-f.]+$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ dma\[[0-f.]+\]: trying delivery$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ dma\[[0-f.]+\]: using smarthost 
> \([._[:alnum:]-]+:[0-9]+\)
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ dma\[[0-f.]+\]: trying remote 
> delivery to [._[:alnum:]-]+ \[[0-9.:]+\] pref [0-9]+$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ dma\[[0-f.]+\]: delivery successful$

> Please, consider adding such rules to logcheck-database

Hi, it's a shame no-one replied since this bug was reported in 2012.
Is there still interest in adding these to logcheck?

It seems good in principal, but im unsure about some of the above:
*  eg dma\[[0-f.]+\] -- normally the bit in [...] would be the pid, so
only 0-9 would be needed?
* user=[[:alpha:]]+ looks more restrictive than most usernames
* if this is email-related i was expecting more "@"s!
* most programs have a "." at the end of messages --- fine if dma does
not of course

(we should  check against the code https://salsa.debian.org/debian/dma
if possible, but a reply confirming onoing interest would be great)

Bug#1002453: logcheck: [logcheck-database] rules for opensmtpd

[Richard Lewis]

On Wed, 22 Dec 2021 11:08:09 +0100 Amadego  wrote:

> These are a proposal for escluding lines that are not harmful:
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ smtpd\[[[:digit:]]+\]: 
> [[:xdigit:]]{16} mta (connecting|connected|disconnected|tls ciphers=).*$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ smtpd\[[[:digit:]]+\]: 
> [[:xdigit:]]{16} mta server-cert-check result="success"$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ smtpd\[[[:digit:]]+\]: 
> [[:xdigit:]]{16} mta delivery .* result="Ok" .*$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ smtpd\[[[:digit:]]+\]: 
> [[:xdigit:]]{16} smtp (connected|disconnected|envelope|message) .*$

Hi, it's a shame no-one replied since 2021 - is this bug still applicable?

the above rules look plausible, but i think we've had a few new
versions since 2021
A check against code at https://salsa.debian.org/debian/opensmtpd
would be great, but a reply is also enough

Bug#625894: logcheck-database: /etc/logcheck/ignore.d.server/spamd regexp broken, triggered by unusual Message-Id

[Richard Lewis]

On Thu, 09 May 2013 14:49:29 -0700 Gerald Turner  wrote:
> Gerald Turner  writes:
> > Hello, there are a few commas that are out of place in one of the
> > spamassassin expressions:
>
> FYI, but is still present in logcheck-database 1.3.15 (wheezy).

(hello again)

It looks like the spamd rules have changed a bit over the last 10
years, is there still a bug in latest rules?

Bug#590674: [logcheck-database] rules for atftpd

[Richard Lewis]

On Wed, 28 Jul 2010 13:47:53 +0200 Hendrik Jaeger  wrote:
> Package: logcheck-database

> We use these rules for atftpd messages:
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ atftpd\[[[:digit:]]+\]:
> timeout: retrying...$ ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+
> atftpd\[[[:digit:]]+\]: Fetching from
> ([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3} to [[:alnum:]\.-]+$

It's a shame no-one replied since 2010 -- let's change that:

Is there still interest in adding these rules to logcheck? if so, are
the rules up-to-date?
i dont object to adding these, but given ftp has declined i wonder if
there is demand for this any more?



A check against https://salsa.debian.org/debian/atftp would be great,
but a reply that this is still useful is enough)

Bug#925248: /etc/logcheck/ignore.d.server/postfix: update rule for log message written when TLS connection is established

[Richard Lewis]

On Fri, 22 Mar 2019 03:41:03 +0900 Yasuhiro KIMURA  wrote:
> There is following rule in ignore.d.server/postfix.
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: 
> ((Anonymous|Trusted|Verified) )?TLS connection established (to|from) 
> [^[:space:]]+: (TLSv1(\.[[:digit:]])?|SSLv[23]) with cipher [^[:space:]]+ 
> \([/[:digit:]]+ bits\)$
>
> This rule is for log message written when TLS connection is established.
> But when TLS 1.3 is used log message is written as following.
>
> Mar 22 03:02:05 mailclient postfix/smtp[12345]: Trusted TLS connection 
> established to mailserver.example.org[192.168.0.1]:25: TLSv1.3 with cipher 
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
> RSA-PSS (4096 bits) server-digest SHA256
>
> And it doesn't match with above rule.
> I checked definition of tls_log_summary()(function that write this
> message) in src/tls/tls_misc.c of Postfix 3.4.4.
> According to it the rule should be updated as following.
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: 
> ((Anonymous|Trusted|Untrusted|Verified) )?TLS connection (established|reused) 
> (to|from) [^[:space:]]+( to [^[:space:]]+)?: (TLSv1(\.[[:digit:]])?|SSLv[23]) 
> with cipher [^[:space:]]+ \([[:digit:]]+/[[:digit:]]+ bits\)( key-exchange 
> [^[:space:]]+( \(([^[:space:]]+|[[:digit:]]+ bits)\))?)?( server-signature 
> [^[:space:]]+( \(([^[:space:]]+|[[:digit:]]+ bits)\))?( server-digest 
> [^[:space:]]+)?)?( client-signature 
> [^[:space:]]+(\(([^[:space:]]+|[[:digit:]]+ bits)\))?( client-digest 
> [^[:space:]]+)?)?$
>


Is this request from 2019 still valid - it looks close, but eg
according to 
https://salsa.debian.org/postfix-team/postfix-dev/-/blob/debian/master/src/tls/tls_misc.c?ref_type=heads#L1216
the first bit is not optional, i struggled to match some of the rest,
eg ([^[:space:]]+|[[:digit:]]+ bits seems a bit odd, since the
"|[[:digit:]]" is not needed

So perhaps this needs updating?

Bug#547774: dovecot-related rules against logcheck

[Richard Lewis]

Hi, logcheck has several old bugs suggesting new rules for dovecot.  It's a
pitty no-one replied, but let's change that now.

Unfortuntely, the patches in these bugs do not cleanly apply to the latest
version. I had a look at updating but not being a dovecot user akes it less
thn feasible

Is there still interest in updating rules for dovecot?

Bug#1070440: mesa-va-drivers: vaapi cannot find target for triple amdgcn

[Richard Rosner]

This must have been because of a local installation of self compiled Mesa that 
I thought I couldn't get to be used by programs. Removing it solved the issue. 
Case closed, sorry about that.

Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Richard Lewis]

On Tue, 28 May 2024 17:15:02 +0100 Luca Boccassi  wrote:
> On Tue, 28 May 2024 17:44:54 +0200 Michael Biebl 
> > Please do not not ship conflicting configuration for /run/lock
> >
> > /usr/lib/tmpfiles.d/debian.conf:d /run/lock1777 root root -   -
> > /usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -

+1

this is really baffling for people who want to understand how debian
sets things up, -- what is the permission meant to be? why has debian
not made up its mind on what the permission is meant to be?

it gives the impression that something has not been thought about
properly, which is presumably not the intention?

If someone wanted to make a local change to permissions,  they would
presumably need to override both files?

Bug#987971: (for post boomworm)

[Richard Lewis]

control: tags -1 wontfix
control: retitle -1 remove logcheck user on purge

Tagging wontfix: debian policy is to not remove system users, since
they may still open files

Bug#401259: logcheck: logcheck needs to override locale for grep

[Richard Lewis]

On Sat, 3 Apr 2010 02:07:20 +0400 Dmitry Semyonov  wrote:
> Another reason to set LC_ALL=C is  grep slowness in UTF-8 locale.
> Depending on used patterns, I saw "grep -E" to be 6 times slower
> compared to C locale, and I guess this was not the worst case. The
> performance problem seems to be fixed in grep-2.6.* but it is not
> available in Debian yet.
>
> --

You can (and have always been able to) add

LC_ALL=C

or LANG=C
or any other locale setting


into logcheck.conf and it will be honoured.
I dont think debian should do this by default - we should assume the locale
is set up correctly - whichbit usually is


So i think we can close this bug.

Bug#198762: logcheck: Rewriting log lines to be more easily human readable

[Richard Lewis]

On Wed, 25 Jun 2003 10:35:02 -0400 Erik Jacobson  wrote:

> While looking through a few pages worth of FTP logs and other such
> things in my logcheck reports, I would think that many people might find
> the ability to have rewrite rules for logcheck.  It would enable
> administrators to sift out a lot of the extra cruft from certain logs
> that may not be relevant to their situation, and even to make certain
> lines stand out more visually then others (either just by using indented
> text or maybe even ansi colors... or something)
>
> Just a little thing that I know I would find usefull for various of the
> logs I monitor without having to write a bunch of scripts to pre process
> the logs.  Of course, I dunno how well this could be achieved with the
> gnu regexps versus running it through somehting else like sed or
> whatever. :)

It's a shame no-one replied properly since 2003. logcheck actually
supports this feature - you can write a local script called
"syslog-summary" and tell logcheck to pass the results through it.
There used to be a debian package, but no-one maintained it and it was removed.

The more i think about this, the more i think we should keep support
for running such a script - i can see it being quite useful in some
situations.
But: i wouldn't want to try and put such a script in logcheck: it's a
whole other project to make something that would be flexible and
usable enough to be worth publishing, and i dont think
it should be part of logcheck -- better to let anyone who wants it do
their own thing.


So we should simply close this bug as the functionality requested is
there, for advanced users.

Bug#690145: bad rule in ignore for saslauthd (patch included)

[Richard Lewis]

On Wed, 10 Oct 2012 09:24:26 -0400 CJ Fearnley  wrote:

> File: /etc/logcheck/ignore.d.server/saslauthd

> The following patch fixes a bug in the regex for ignoring
> useless lines from saslauthd authentication failures
> (/etc/logcheck/ignore.d.server/saslauthd) on this Squeeze system:
>

> -^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ saslauthd\[[[:digit:]]+\]: 
> \(pam_unix\) check pass; user unknown$
> +^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ saslauthd\[[[:digit:]]+\]: 
> pam_unix\(:auth\): check pass; user unknown$

This looks to still apply some 12 years later, in the sense that the rules have

: \(pam_unix\) check pass; user unknown$

But im unclear that the new line ' pam_unix\(:auth\): check pass; user
unknown' is the right solution in 2024 - I'd expect something like:
  pam_unix\(:auth\): check pass; user unknown$

but i dont know what the  would be.

Think we need an update before this can be applied.

Bug#617232: logcheck: ignore regexes match ipv4 addresses only, causing false positives with ipv6 addresses.

[Richard Lewis]

On Mon, 07 Mar 2011 11:19:04 + "Benjamin M. A'Lee"
 wrote:


> Various files under ignore.d.* use "[0-9.]{7,15}" to match an IPv4
> address, e.g., a connection to rsyncd. However, this does not match
> IPv6 addresses, causing spurious reports.
>
> A better regexp might be something like: ([0-9.]{7,15}|[0-9a-f:]{2,39})

This but has been open since 2011, it's a bit too vague to really action.

- making rules cover IPv6 is definitely what we want
- I can see that [0-9.]{7,15} appears in several files, but it's not
clear that these also support IPv6, or even that they are for $IPs.
- (none are in things im familiar with - maintaining such rules is
difficult as you dont know what can/can't be safely changed -
obviously
   this is a bit of a cop-out as widening a match like this should be
safe, but it;s too easy to make a typo and break things.
   im working on 'macros', so we can define write $IP in rules and
define this to be [0-9.]+ (or [0-9a-f:.]+ etc), this definitely helps
   make writing and updating rules nicer. it doesnt really address
this issue , but might make it easier to review patches
- I'll be proposing various rules-related things, but not sure it covers this
- Updating rules for software you dont use is a bit of a pain.

but, (and reluctantly),  i propose to close this particular bug due to
lack of specific enough examples - but will review any patches if
anyone is watching! (ideally, we
would track which bits of code produce each message -- someone did
this for the sudo rules and it really helps keep it up-to-date)

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear Neil,

I was running it on arm64, may that be the reason?

Regards,
Richard

On May 27, 2024 4:02:32 AM GMT+02:00, NeilBrown  wrote:
>On Sun, 26 May 2024, Richard Kojedzinszky wrote:
>> Dear Neil,
>> 
>> According to my quick tests, your patch seems to fix this bug. Could you 
>> also manage to try my attached code, could you also reproduce the bug?
>
>Thanks for testing.
>
>I can run your test code but it isn't triggering the bug (90 minutes so
>far).  Possibly a different compiler used for the kernel, possibly
>hardware differences (I'm running under qemu).  Bugs related to barriers
>(which this one seems to be) need just the right circumstances to
>trigger so they can be hard to reproduce on a different system.
>
>I've made some cosmetic improvements to the patch and will post it to
>the NFS maintainers.
>
>Thanks again,
>NeilBrown
>
>
>> 
>> Thanks,
>> Richard
>> 
>> 2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:
>> > Dear Neil,
>> > 
>> > I've applied your patch, and since then there are no lockups. Before 
>> > that my application reported a lockup in a minute or two, now it has 
>> > been running for half an hour, and still running.
>> > 
>> > Thanks,
>> > Richard
>> > 
>> > 2024-05-24 01:31 időpontban NeilBrown ezt írta:
>> >> On Fri, 24 May 2024, Richard Kojedzinszky wrote:
>> >>> Dear devs,
>> >>> 
>> >>> I am attaching a stripped down version of the little program which
>> >>> triggers the bug very quickly, in a few minutes in my test lab. It
>> >>> turned out that a single NFS mountpoint is enough. Just start the
>> >>> program giving it the NFS mount as first argument. It will chdir 
>> >>> there,
>> >>> and do file operations, which will trigger a lockup in a few minutes.
>> >> 
>> >> I couldn't get the go code to run.  But then it is a long time since I
>> >> played with go and I didn't try very hard.
>> >> If you could provide simple instructions and a list of package
>> >> dependencies that I need to install (on Debian), I can give it a try.
>> >> 
>> >> Or you could try this patch.  It might help, but I don't have high
>> >> hopes.  It adds some memory barriers and fixes a bug which would cause 
>> >> a
>> >> problem if memory allocation failed (but memory allocation never 
>> >> fails).
>> >> 
>> >> NeilBrown
>> >> 
>> >> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
>> >> index ac505671efbd..5bcc0d14d519 100644
>> >> --- a/fs/nfs/dir.c
>> >> +++ b/fs/nfs/dir.c
>> >> @@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry, 
>> >> unsigned int flags,
>> >>   } else {
>> >>   /* Wait for unlink to complete */
>> >>   wait_var_event(>d_fsdata,
>> >> -dentry->d_fsdata != NFS_FSDATA_BLOCKED);
>> >> +smp_load_acquire(>d_fsdata) != 
>> >> NFS_FSDATA_BLOCKED);
>> >>   parent = dget_parent(dentry);
>> >>   ret = reval(d_inode(parent), dentry, flags);
>> >>   dput(parent);
>> >> @@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry 
>> >> *dentry)
>> >>   spin_unlock(>d_lock);
>> >>   error = nfs_safe_remove(dentry);
>> >>   nfs_dentry_remove_handle_error(dir, dentry, error);
>> >> - dentry->d_fsdata = NULL;
>> >> + smp_store_release(>d_fsdata, NULL);
>> >>   wake_up_var(>d_fsdata);
>> >>  out:
>> >>   trace_nfs_unlink_exit(dir, dentry, error);
>> >> @@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct 
>> >> nfs_renamedata *data)
>> >>  {
>> >>   struct dentry *new_dentry = data->new_dentry;
>> >> 
>> >> - new_dentry->d_fsdata = NULL;
>> >> + smp_store_release(_dentry->d_fsdata, NULL);
>> >>   wake_up_var(_dentry->d_fsdata);
>> >>  }
>> >> 
>> >> @@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct 
>> >> inode *old_dir,
>> >>   task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
>> >>   must_unblock ? nfs_unblock_rename : NULL);
>> >>   if (IS_ERR(task)) {
>> >> + if (must_unlock) {
>> >> + smp_store_release(_dentry->d_fsdata, NULL);
>> >> + wake_up_var(_dentry->d_fsdata);
>> >> + }
>> >>   error = PTR_ERR(task);
>> >>   goto out;
>> >>   }
>> 
>

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear Neil,

According to my quick tests, your patch seems to fix this bug. Could you 
also manage to try my attached code, could you also reproduce the bug?


Thanks,
Richard

2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:

Dear Neil,

I've applied your patch, and since then there are no lockups. Before 
that my application reported a lockup in a minute or two, now it has 
been running for half an hour, and still running.


Thanks,
Richard

2024-05-24 01:31 időpontban NeilBrown ezt írta:

On Fri, 24 May 2024, Richard Kojedzinszky wrote:

Dear devs,

I am attaching a stripped down version of the little program which
triggers the bug very quickly, in a few minutes in my test lab. It
turned out that a single NFS mountpoint is enough. Just start the
program giving it the NFS mount as first argument. It will chdir 
there,

and do file operations, which will trigger a lockup in a few minutes.


I couldn't get the go code to run.  But then it is a long time since I
played with go and I didn't try very hard.
If you could provide simple instructions and a list of package
dependencies that I need to install (on Debian), I can give it a try.

Or you could try this patch.  It might help, but I don't have high
hopes.  It adds some memory barriers and fixes a bug which would cause 
a
problem if memory allocation failed (but memory allocation never 
fails).


NeilBrown

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index ac505671efbd..5bcc0d14d519 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry, 
unsigned int flags,

} else {
/* Wait for unlink to complete */
wait_var_event(>d_fsdata,
-  dentry->d_fsdata != NFS_FSDATA_BLOCKED);
+  smp_load_acquire(>d_fsdata) != 
NFS_FSDATA_BLOCKED);
parent = dget_parent(dentry);
ret = reval(d_inode(parent), dentry, flags);
dput(parent);
@@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry 
*dentry)

spin_unlock(>d_lock);
error = nfs_safe_remove(dentry);
nfs_dentry_remove_handle_error(dir, dentry, error);
-   dentry->d_fsdata = NULL;
+   smp_store_release(>d_fsdata, NULL);
wake_up_var(>d_fsdata);
 out:
trace_nfs_unlink_exit(dir, dentry, error);
@@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct 
nfs_renamedata *data)

 {
struct dentry *new_dentry = data->new_dentry;

-   new_dentry->d_fsdata = NULL;
+   smp_store_release(_dentry->d_fsdata, NULL);
wake_up_var(_dentry->d_fsdata);
 }

@@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct 
inode *old_dir,

task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
must_unblock ? nfs_unblock_rename : NULL);
if (IS_ERR(task)) {
+   if (must_unlock) {
+   smp_store_release(_dentry->d_fsdata, NULL);
+   wake_up_var(_dentry->d_fsdata);
+   }
error = PTR_ERR(task);
goto out;
}

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear Neil,

I've applied your patch, and since then there are no lockups. Before 
that my application reported a lockup in a minute or two, now it has 
been running for half an hour, and still running.


Thanks,
Richard

2024-05-24 01:31 időpontban NeilBrown ezt írta:

On Fri, 24 May 2024, Richard Kojedzinszky wrote:

Dear devs,

I am attaching a stripped down version of the little program which
triggers the bug very quickly, in a few minutes in my test lab. It
turned out that a single NFS mountpoint is enough. Just start the
program giving it the NFS mount as first argument. It will chdir 
there,

and do file operations, which will trigger a lockup in a few minutes.


I couldn't get the go code to run.  But then it is a long time since I
played with go and I didn't try very hard.
If you could provide simple instructions and a list of package
dependencies that I need to install (on Debian), I can give it a try.

Or you could try this patch.  It might help, but I don't have high
hopes.  It adds some memory barriers and fixes a bug which would cause 
a
problem if memory allocation failed (but memory allocation never 
fails).


NeilBrown

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index ac505671efbd..5bcc0d14d519 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry, 
unsigned int flags,

} else {
/* Wait for unlink to complete */
wait_var_event(>d_fsdata,
-  dentry->d_fsdata != NFS_FSDATA_BLOCKED);
+  smp_load_acquire(>d_fsdata) != 
NFS_FSDATA_BLOCKED);
parent = dget_parent(dentry);
ret = reval(d_inode(parent), dentry, flags);
dput(parent);
@@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry 
*dentry)

spin_unlock(>d_lock);
error = nfs_safe_remove(dentry);
nfs_dentry_remove_handle_error(dir, dentry, error);
-   dentry->d_fsdata = NULL;
+   smp_store_release(>d_fsdata, NULL);
wake_up_var(>d_fsdata);
 out:
trace_nfs_unlink_exit(dir, dentry, error);
@@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct 
nfs_renamedata *data)

 {
struct dentry *new_dentry = data->new_dentry;

-   new_dentry->d_fsdata = NULL;
+   smp_store_release(_dentry->d_fsdata, NULL);
wake_up_var(_dentry->d_fsdata);
 }

@@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct 
inode *old_dir,

task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
must_unblock ? nfs_unblock_rename : NULL);
if (IS_ERR(task)) {
+   if (must_unlock) {
+   smp_store_release(_dentry->d_fsdata, NULL);
+   wake_up_var(_dentry->d_fsdata);
+   }
error = PTR_ERR(task);
goto out;
}

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear Neil,

I've stripped the code more, which still triggers the bug for me. On 
Bookworm, to get the binary, simply:


$ sudo apt-get install golang
$ go build .

And then give it an nfs mountpoint, e.g.:

$ ./ds /mnt/nfs

Meanwhile, I will try your patch too.

Regards,
Richard

2024-05-24 01:31 időpontban NeilBrown ezt írta:

On Fri, 24 May 2024, Richard Kojedzinszky wrote:

Dear devs,

I am attaching a stripped down version of the little program which
triggers the bug very quickly, in a few minutes in my test lab. It
turned out that a single NFS mountpoint is enough. Just start the
program giving it the NFS mount as first argument. It will chdir 
there,

and do file operations, which will trigger a lockup in a few minutes.


I couldn't get the go code to run.  But then it is a long time since I
played with go and I didn't try very hard.
If you could provide simple instructions and a list of package
dependencies that I need to install (on Debian), I can give it a try.

Or you could try this patch.  It might help, but I don't have high
hopes.  It adds some memory barriers and fixes a bug which would cause 
a
problem if memory allocation failed (but memory allocation never 
fails).


NeilBrown

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index ac505671efbd..5bcc0d14d519 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry, 
unsigned int flags,

} else {
/* Wait for unlink to complete */
wait_var_event(>d_fsdata,
-  dentry->d_fsdata != NFS_FSDATA_BLOCKED);
+  smp_load_acquire(>d_fsdata) != 
NFS_FSDATA_BLOCKED);
parent = dget_parent(dentry);
ret = reval(d_inode(parent), dentry, flags);
dput(parent);
@@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry 
*dentry)

spin_unlock(>d_lock);
error = nfs_safe_remove(dentry);
nfs_dentry_remove_handle_error(dir, dentry, error);
-   dentry->d_fsdata = NULL;
+   smp_store_release(>d_fsdata, NULL);
wake_up_var(>d_fsdata);
 out:
trace_nfs_unlink_exit(dir, dentry, error);
@@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct 
nfs_renamedata *data)

 {
struct dentry *new_dentry = data->new_dentry;

-   new_dentry->d_fsdata = NULL;
+   smp_store_release(_dentry->d_fsdata, NULL);
wake_up_var(_dentry->d_fsdata);
 }

@@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct 
inode *old_dir,

task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
must_unblock ? nfs_unblock_rename : NULL);
if (IS_ERR(task)) {
+   if (must_unlock) {
+   smp_store_release(_dentry->d_fsdata, NULL);
+   wake_up_var(_dentry->d_fsdata);
+   }
error = PTR_ERR(task);
goto out;
}


ds.tar
Description: Unix tar archive

Bug#761813: grep and locales

[Richard Lewis]

On Tue, 14 Mar 2023 10:19:19 -0400 Simon Deziel  wrote:
> On 2023-03-14 08:49, Richard Lewis wrote:
> > On Mon, 13 Mar 2023, 12:36 Simon Deziel,  wrote:
> >
> >> egrep still consumes a lot of memory for me. A workaround I've been
> >> using is to add this to /etc/logcheck/logcheck.conf:
> >>
> >> # XXX: prevent grep from using incredible amounts of RAM (>3G RSS)
> >> #  this also speeds up grep a lot
> >> export LC_ALL=C

Returning to this after a while: I think the above -- setting LC_ALL
in logcheck.conf  is probably the best solution available.

So we might even close this bug, as im not sure what else logcheck can do?


> > interesting - does using C.UTF-8 have the same effect?
>
> tl; dr: no :/

Thanks for testing. I suppose the underlying issue is in grep. I hope
that later versions of logcheck will allow to swap grep for ag or
ripgrep -- but they are faster at the cost of more RAM, at least
sometimes

Bug#630721: logcheck: improve support for non-POSIX charsets in generated report

[Richard Lewis]

On Thu, 16 Jun 2011 16:38:49 +0200 Nenad Cimerman
 wrote:

TLDR: some time in the last 15 years, this bug against logcheck has
been fixed, as far as i can tell

> My system is setup with non-POSIX default locale (see below), using UTF-8
> character encoding.

> This leads to many lines inside various log files (e.g. /var/log/syslog)
> containing 'german umlaut' characters (äöüÄÖÜß).

> Details...
>
> The script /usr/sbin/logcheck is usually run by the cron deamon, based on
> /etc/cron.d/logcheck. This process runs in POSIX locale (LC_ALL=POSIX,
> LANG=POSIX), despite /etc/default/locale being possibly set to a different

You can set a different LANG in logcheck.conf if you need

> Inside /usr/sbin/logcheck, the function sendreport() uses mail(1) or nail(1)

logcheck now uses mime-construct(1) instead of either of these

> By default, reports are sent 'inline' (not as an attachment)

This can also be controlled with the MAILASATTACH option

> Unfortunately mail(1) is responsible for the characterset issue, as it does
> ignore the locale settings completely.

mime-construct allows the charset to be set using the MIMEENCODING
option in logcheck.conf

So i think we can close this bug.

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear devs,

I am attaching a stripped down version of the little program which 
triggers the bug very quickly, in a few minutes in my test lab. It 
turned out that a single NFS mountpoint is enough. Just start the 
program giving it the NFS mount as first argument. It will chdir there, 
and do file operations, which will trigger a lockup in a few minutes.


Please take a look at it.

Thanks in advance,
Richard

2024-05-23 14:12 időpontban Richard Kojedzinszky ezt írta:

Dear devs,

Now bisecting turned out that 3c59366c207e4c6c6569524af606baf017a55c61 
is the bad commit for me. Strangely it only affects my dovecot process 
accessing data over NFS.


Can you please confirm that this may be a bad commit?

My earlier attached programs may be used to demonstrate/trigger the 
issue. It even could be stripped down to minimal operations to trigger 
the bug.


Thanks in advance,
Richard


2024-05-23 09:10 időpontban Richard Kojedzinszky ezt írta:

Dear NFS developers,

I am running multiple PODs on a Kubernetes node, they all mount 
different NFS shares from the same nfs server. I started to notice 
hangups in my dovecot process after I switched to Debian's kernel from 
upstream 5.15. You can find Debian bugreport at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501.


So, effectively I am running dovecot in Kubernetes, and dovecot's data 
directory is accessed over NFS. Eventually one dovecot process stucks 
in nfs4_lookup_revalidate(). From that point, that process cannot be 
killed, howewer, other processes can access NFS as normal. Also, 
another dovecot process running on the very same node accessing the 
same NFS share works too.


Now, I am still in the process of bisecting, howewer, I cannot 
reliably trigger the bug. Originally it took a few days after I've 
noticed a hanging process. Now I am trying to mimic file operations 
what dovecot does in a faster way. Now it seems that it triggers the 
bug in a few hours, howewer, during bisects, I can still make 
mistakes.


I've scheduled many of my applications which use NFS shares to the 
same node, to have more NFS load on that node.


I am attaching my simple app which triggers the bug in a few hours, at 
least in my lab. I have two dedicated NFS shares for this test case, 
and I am running 3 instances of the applications for both shares. 
Also, I am running other production applications on the same node 
which also use NFS, howewer, I dont experience lockups with them. They 
are librenms, prometheus, and a docker private registry. This way I 
dont know if running the attached app only is enough to trigger the 
bug.


Once I have a suspectible commit based on my bisecting process, I will 
report it here.


My NFS server is a TrueNAS, based on FreeBSD 13.3.

Thanks in advance,
Richard


ds.tar
Description: Unix tar archive

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear devs,

Now bisecting turned out that 3c59366c207e4c6c6569524af606baf017a55c61 
is the bad commit for me. Strangely it only affects my dovecot process 
accessing data over NFS.


Can you please confirm that this may be a bad commit?

My earlier attached programs may be used to demonstrate/trigger the 
issue. It even could be stripped down to minimal operations to trigger 
the bug.


Thanks in advance,
Richard


2024-05-23 09:10 időpontban Richard Kojedzinszky ezt írta:

Dear NFS developers,

I am running multiple PODs on a Kubernetes node, they all mount 
different NFS shares from the same nfs server. I started to notice 
hangups in my dovecot process after I switched to Debian's kernel from 
upstream 5.15. You can find Debian bugreport at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501.


So, effectively I am running dovecot in Kubernetes, and dovecot's data 
directory is accessed over NFS. Eventually one dovecot process stucks 
in nfs4_lookup_revalidate(). From that point, that process cannot be 
killed, howewer, other processes can access NFS as normal. Also, 
another dovecot process running on the very same node accessing the 
same NFS share works too.


Now, I am still in the process of bisecting, howewer, I cannot reliably 
trigger the bug. Originally it took a few days after I've noticed a 
hanging process. Now I am trying to mimic file operations what dovecot 
does in a faster way. Now it seems that it triggers the bug in a few 
hours, howewer, during bisects, I can still make mistakes.


I've scheduled many of my applications which use NFS shares to the same 
node, to have more NFS load on that node.


I am attaching my simple app which triggers the bug in a few hours, at 
least in my lab. I have two dedicated NFS shares for this test case, 
and I am running 3 instances of the applications for both shares. Also, 
I am running other production applications on the same node which also 
use NFS, howewer, I dont experience lockups with them. They are 
librenms, prometheus, and a docker private registry. This way I dont 
know if running the attached app only is enough to trigger the bug.


Once I have a suspectible commit based on my bisecting process, I will 
report it here.


My NFS server is a TrueNAS, based on FreeBSD 13.3.

Thanks in advance,
Richard

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear NFS developers,

I am running multiple PODs on a Kubernetes node, they all mount 
different NFS shares from the same nfs server. I started to notice 
hangups in my dovecot process after I switched to Debian's kernel from 
upstream 5.15. You can find Debian bugreport at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501.


So, effectively I am running dovecot in Kubernetes, and dovecot's data 
directory is accessed over NFS. Eventually one dovecot process stucks in 
nfs4_lookup_revalidate(). From that point, that process cannot be 
killed, howewer, other processes can access NFS as normal. Also, another 
dovecot process running on the very same node accessing the same NFS 
share works too.


Now, I am still in the process of bisecting, howewer, I cannot reliably 
trigger the bug. Originally it took a few days after I've noticed a 
hanging process. Now I am trying to mimic file operations what dovecot 
does in a faster way. Now it seems that it triggers the bug in a few 
hours, howewer, during bisects, I can still make mistakes.


I've scheduled many of my applications which use NFS shares to the same 
node, to have more NFS load on that node.


I am attaching my simple app which triggers the bug in a few hours, at 
least in my lab. I have two dedicated NFS shares for this test case, and 
I am running 3 instances of the applications for both shares. Also, I am 
running other production applications on the same node which also use 
NFS, howewer, I dont experience lockups with them. They are librenms, 
prometheus, and a docker private registry. This way I dont know if 
running the attached app only is enough to trigger the bug.


Once I have a suspectible commit based on my bisecting process, I will 
report it here.


My NFS server is a TrueNAS, based on FreeBSD 13.3.

Thanks in advance,
Richard

ds.tar
Description: Unix tar archive

Bug#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear Salvatore,

I've already started bisecting. It will take some time. Usually the bug 
appears after a few hours, unfortunately I am not able to trigger it 
faster. So, if the bug appears, I can step forward easily, but if not, 
its hard to decide if it is still present and simply just have not 
occured, or if the current version is a good one. I'll try to do my 
best.


I will also contact linux-nfs mailing list.

As I remember, it started nearly a year ago, when I switched to Debian's 
kernel. I dont know exactly what version was at that time. Howewer, I've 
checked Debian's patches, and I did not find anything related to NFS.


Regards,
Richard


2024-05-20 21:07 időpontban Salvatore Bonaccorso ezt írta:

Hi Richard,

On Mon, May 20, 2024 at 09:27:24AM +, Richard Kojedzinszky wrote:

Package: src:linux
Version: 6.1.90-1
Severity: normal
X-Debbugs-Cc: richard+debian+bugrep...@kojedz.in

Dear Maintainer,

I am running kubernetes on debian, and pods are mounting multiple nfs
shares. I am running dovecot processes in PODs, which receive mails 
from

the internet, and also serves as imap server for clients. I am
monitoring my mail system by sending mails periodically (15 seconds) 
and
also downloading them via imap. I found a few times that some dovecot 
process
stuck in D state, a reboot was always needed to recover from that 
state.


Unfortunately, I was not able to trigger the bug really fast, I dont
really know what operations does dovecot issue and in what order to 
trigger
this behavior. So until I get closer, I've set up a similar, but 
smaller

environment with just a single dovecot process, and it also does the
same work, delivering only test mails locally, and serving them via 
imap
to the monitoring client, storing everything on NFS. Fortunately, this 
also
triggers the bug, after a few hours one of the dovecot processes is 
stuck

in D state. Kernel also shows blocked state:


As you seem in the lucky position to be able to trigger the issue in a
more localized setup, might you:

- try as well more recent kernels from upper suites (6.8.9-1 in
  unstable would be ideal to check if the issue is there as well).
- I did read you cannot trigger with 5.15. If you build 6.1.90 from
  upstream without Debian patches I assume you can trigger the issue
  likewise? If so could you bisect the changes introducing the issue?
  This is a cumbersome process in particular if you need few hours to
  trigger it  So maybe the following point could be done first:
- Can you report the issue to the linux-nfs list, keeping us in the
  loop?

Regards,
Salvatore

Bug#1071556: Acknowledgement (Dvorak keymap not loaded after login)

[Daniel Richard G.]

I've reported this issue to the upstream project at

https://github.com/neutrinolabs/xrdp/issues/3081

Ubuntu's version 0.9.24-4 in 24.04/noble is likewise affected.

Bug#1071556: Dvorak keymap not loaded after login

[Daniel Richard G.]

Package: xrdp
Version: 0.9.24-5
Severity: important

Recently, I have noticed that logging in via a recent version of xrdp,
while using the Dvorak layout on the client, yields a QWERTY layout in
the remote framebuffer after getting past the login dialog. This is
incorrect behavior and has never happened before.

After some digging, I tracked the problem down to this:

https://bugs.debian.org/1063725

It is no longer possible to refer to the Dvorak layout as just "dvorak"
(as when one would run "setxkbmap dvorak"); one must now use either
"us dvorak" or "us(dvorak)". The below edit fixes the issue and allows
me the proper keymap after logging in:

--- /etc/xrdp/xrdp_keyboard.ini.orig
+++ /etc/xrdp/xrdp_keyboard.ini
@@ -86,7 +86,7 @@
 ;  = 
 [default_layouts_map]
 rdp_layout_us=us
-rdp_layout_us_dvorak=dvorak
+rdp_layout_us_dvorak=us(dvorak)
 rdp_layout_us_dvp=us(dvp)
 rdp_layout_dk=dk
 rdp_layout_de=de
@@ -125,7 +125,7 @@
 
 [rdp_layouts_map_mac]
 rdp_layout_us=us
-rdp_layout_us_dvorak=dvorak
+rdp_layout_us_dvorak=us(dvorak)
 rdp_layout_us_dvp=us(dvp)
 rdp_layout_dk=dk
 rdp_layout_de=de


--Daniel

Bug#1071426: logcheck-database: smartd: Match nvme lines too

[Richard Lewis]

On Sun, 19 May 2024 at 05:06, Stefanos Harhalakis  wrote:

> See attached patch for matching NVMe devices too in smartd logs

Thanks - yes i'd noticed that the rules for smartd need an update and
this is on the radar - however, the
update to the names of the .state files i was not aware of!

I think the first part of the patch is  not quite right, per the code
i think it should be:

# from https://sources.debian.org/src/smartmontools/7.4-2/smartd.cpp/#L5829
... Monitoring [[:digit:]]+ ATA/SATA, [[:digit:]]+ SCSI/SAS and
[[:digit:]]+ NVMe devices

It would be really helpful if you could:

1/ send some sample log output logs,

something like:
journalctl -t smartd | awk '{$1=$2=$3=$4="";$5="X";print}' | sort -u

would be helpful

I'm especially unsure about the bits of rules that start "Device:" as
i could not work out what format is expected -- the current rules have
Device: /dev/[^[:space:]]+( \[[_/[:alnum:][:space:]]+\])?( \[SAT\])?
but im not sure if the optional groups are up-to-date, -- i couldnt
find what bit of code determines those.

2/ the attached rules (untested) are what i'm wokring on for smartd -
any testing of these would be great
(I generalised the name of the .state file - again i dont know where
smartd sets this bit, so hard to know what is expected!)
(these are completely untested, so may be completely broken)


smartd.rules
Description: Binary data

Bug#1071377: chkrootkit: File name including a quote mark throws script off

[Richard Lewis]

On Sat, 18 May 2024 at 08:39, Shai Berger  wrote:

> This morning, when chkrootkit made its daily run, I had
> in /tmp a file named: 'חברת חשמל לישראל בע"מ - חשבון דו חודשי.pdf'
> (the single quote marks on the edges are not part of the name, but
> the double quote mark in the middle is)
>
> This caused this output from the script:
>
> """
> Searching for suspect PHP files...  /usr/bin/head: 
> cannot open '/tmp/חברת חשמל לישראל בעמ' for reading: No such file or directory
> /usr/bin/head: cannot open 'חשבון' for reading: No such file or directory
> /usr/bin/head: cannot open 'דו' for reading: No such file or directory
> /usr/bin/head: cannot open 'חודשי.pdf 2>/dev/null | /usr/bin/grep -q ^#!.*php 
> && echo /tmp/חברת' for reading: No such file or directory
> /usr/bin/head: cannot open 'חשמל' for reading: No such file or directory
> /usr/bin/head: cannot open 'לישראל' for reading: No such file or directory
> /usr/bin/head: cannot open 'בעמ - חשבון דו חודשי.pdf' for reading: No such 
> file or directory
> WARNING

Thanks, yes this is probably also bug in upstream as well, but there
are debian-specific patches that make this worse. Will fix.

Patches also welcome - it's patch number 16 in debian/patches that has
the PHP check.

Bug#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Package: src:linux
Version: 6.1.90-1
Severity: normal
X-Debbugs-Cc: richard+debian+bugrep...@kojedz.in

Dear Maintainer,

I am running kubernetes on debian, and pods are mounting multiple nfs
shares. I am running dovecot processes in PODs, which receive mails from
the internet, and also serves as imap server for clients. I am
monitoring my mail system by sending mails periodically (15 seconds) and
also downloading them via imap. I found a few times that some dovecot process
stuck in D state, a reboot was always needed to recover from that state.

Unfortunately, I was not able to trigger the bug really fast, I dont
really know what operations does dovecot issue and in what order to trigger
this behavior. So until I get closer, I've set up a similar, but smaller
environment with just a single dovecot process, and it also does the
same work, delivering only test mails locally, and serving them via imap
to the monitoring client, storing everything on NFS. Fortunately, this also
triggers the bug, after a few hours one of the dovecot processes is stuck
in D state. Kernel also shows blocked state:

May 19 12:16:49 k8s-node07 kernel: INFO: task lmtp:665683 blocked for more than 
120 seconds.
May 19 12:16:49 k8s-node07 kernel:   Not tainted 6.1.0-21-arm64 #1 Debian 
6.1.90-1
May 19 12:16:49 k8s-node07 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 19 12:16:49 k8s-node07 kernel: task:lmtpstate:D stack:0 
pid:665683 ppid:2881   flags:0x
May 19 12:16:49 k8s-node07 kernel: Call trace:
May 19 12:16:49 k8s-node07 kernel:  __switch_to+0xf0/0x170
May 19 12:16:49 k8s-node07 kernel:  __schedule+0x340/0x940
May 19 12:16:49 k8s-node07 kernel:  schedule+0x58/0xf0
May 19 12:16:49 k8s-node07 kernel:  __nfs_lookup_revalidate+0x118/0x160 [nfs]
May 19 12:16:49 k8s-node07 kernel:  nfs4_lookup_revalidate+0x20/0x30 [nfs]
May 19 12:16:49 k8s-node07 kernel:  lookup_fast+0x138/0x150
May 19 12:16:49 k8s-node07 kernel:  walk_component+0x30/0x1a0
May 19 12:16:49 k8s-node07 kernel:  path_lookupat+0x80/0x1a4
May 19 12:16:49 k8s-node07 kernel:  filename_lookup+0xb4/0x1b0
May 19 12:16:49 k8s-node07 kernel:  vfs_statx+0x94/0x19c
May 19 12:16:49 k8s-node07 kernel:  vfs_fstatat+0x68/0x90
May 19 12:16:49 k8s-node07 kernel:  __do_sys_newfstatat+0x58/0xa0
May 19 12:16:49 k8s-node07 kernel:  __arm64_sys_newfstatat+0x28/0x34
May 19 12:16:49 k8s-node07 kernel:  invoke_syscall+0x78/0x100
May 19 12:16:49 k8s-node07 kernel:  el0_svc_common.constprop.0+0x4c/0xf4
May 19 12:16:49 k8s-node07 kernel:  do_el0_svc+0x34/0xd0
May 19 12:16:49 k8s-node07 kernel:  el0_svc+0x34/0xd4
May 19 12:16:49 k8s-node07 kernel:  el0t_64_sync_handler+0xf4/0x120
May 19 12:16:49 k8s-node07 kernel:  el0t_64_sync+0x18c/0x190

Or, for another process:

May 20 04:50:01 k8s-node07 kernel: INFO: task imap:8337 blocked for more than 
120 seconds.
May 20 04:50:01 k8s-node07 kernel:   Not tainted 6.1.0-21-arm64 #1 Debian 
6.1.90-1
May 20 04:50:01 k8s-node07 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 20 04:50:01 k8s-node07 kernel: task:imapstate:D stack:0 
pid:8337  ppid:3164   flags:0x
May 20 04:50:01 k8s-node07 kernel: Call trace:
May 20 04:50:01 k8s-node07 kernel:  __switch_to+0xf0/0x170
May 20 04:50:01 k8s-node07 kernel:  __schedule+0x340/0x940
May 20 04:50:01 k8s-node07 kernel:  schedule+0x58/0xf0
May 20 04:50:01 k8s-node07 kernel:  __nfs_lookup_revalidate+0x118/0x160 [nfs]
May 20 04:50:01 k8s-node07 kernel:  nfs4_lookup_revalidate+0x20/0x30 [nfs]
May 20 04:50:01 k8s-node07 kernel:  lookup_fast+0x138/0x150
May 20 04:50:01 k8s-node07 kernel:  walk_component+0x30/0x1a0
May 20 04:50:01 k8s-node07 kernel:  path_lookupat+0x80/0x1a4
May 20 04:50:01 k8s-node07 kernel:  filename_lookup+0xb4/0x1b0
May 20 04:50:01 k8s-node07 kernel:  vfs_statx+0x94/0x19c
May 20 04:50:01 k8s-node07 kernel:  vfs_fstatat+0x68/0x90
May 20 04:50:01 k8s-node07 kernel:  __do_sys_newfstatat+0x58/0xa0
May 20 04:50:01 k8s-node07 kernel:  __arm64_sys_newfstatat+0x28/0x34
May 20 04:50:01 k8s-node07 kernel:  invoke_syscall+0x78/0x100
May 20 04:50:01 k8s-node07 kernel:  el0_svc_common.constprop.0+0x4c/0xf4
May 20 04:50:01 k8s-node07 kernel:  do_el0_svc+0x34/0xd0
May 20 04:50:01 k8s-node07 kernel:  el0_svc+0x34/0xd4
May 20 04:50:01 k8s-node07 kernel:  el0t_64_sync_handler+0xf4/0x120
May 20 04:50:01 k8s-node07 kernel:  el0t_64_sync+0x18c/0x190


Of course the NFS server is running, and other NFS mounts are still
working from the node. Also, this started to happen with Debian's
kernel. Before that, I was compiling my own upstream kernel, version
5.15. With that, I've never experienced such a lockup.

Unfortunately, I dont know, how to go further, how shall I collect more
relevant debugging information.

I expect thet dovecot is just an application, which should not cause any
kernel-side lockups. In my test lab, this specific NFS mount is just
mounted on one machine

Bug#358965: RE: bash: Please support setting terminal title for screen

[Richard Lewis]

On Sun, 4 May 2014 22:33:23 +1000 Scott Leggett  wrote:
> I just spent half an hour figuring out how to get window titles to
> reflect my session in byobu.. and I find the exact patch required is
> already here (thanks Josh).
>
> I guess this is just a +1 for patching skel.bashrc so that ssh-ing into
> machines via byobu does The Right Thing to your terminal emulator's
> window title automatically.
>
> --
> Regards,
> Scott Leggett


The screen manpage explains this, and recommends a slightly different
formulation for escaping  --- might want to use that for consistency:


PROMPT_COMMAND='printf "\033k\033\134"'

Bug#625895: logcheck-database: /etc/logcheck/ignore.d.server/dovecot rule misses unusual Message-Id

[Richard Lewis]

On Fri, 06 May 2011 11:32:03 -0700 Gerald Turner  wrote:

> Hello, I've seen some legitimate mails with unusual Message-Id headers
> that cause logchecks dovecot delivery rule to be bypassed.
>
> Example: … sieve: msgid=<20110422T2108.GA.(stdi.s...@fsing.rootsland.net>: 
> stored mail into mailbox 'Mailing Lists/Debian/debian-devel'

It's a shame no-one replied since 2011.

That doesnt seem to be a valid msgid, so not sure logcheck should be
ignoring it by default. Obviously you can edit / make your own rules
to do so.
So not sure there is anything for debian to do in this one. Perhaps we
should close the bug?

Bug#491127: logcheck: please consider an option which will always check the entire log file

[Richard Lewis]

On Sun, 12 May 2024 at 19:57, Marc Haber  wrote:
>
> On Sun, May 12, 2024 at 06:54:59PM +0100, R Lewis wrote:
> > On Wed, 16 Jul 2008 23:15:51 +0200 Marc Haber
> >  wrote:
> >
> > > It would help with debugging to have an option that causes logcheck to
> > > always look through the entire log file, ie not using logtail.
> >
> > Looking at this old bug from 2008: does the -t option meet this need?
>
> Not quite. Imagine: I have a system running logcheck hourly. At 11:00, I
> get a mail with a log message from 10:55 that is not yet covered by the
> rule. The stamp gets updated to 11:00.
>
> I now fix the rule that should have filtered the message. logcheck -t
> will still only start checking a 11:00, so the test run will not prove
> that the change has actually filtered the message from 10:55.
>
> Does this make the usecase clear?

Does logcheck-test help with that?

Bug#975694: [logcheck-database] stop filtering smartd attribute change events

[Richard Lewis]

control: tags -1 + moreinfo
thanks

On Wed, 25 Nov 2020 13:13:14 +0500 Alex Volkov  wrote:

> IDK how it was in 2006 when this stupid decision was made, but nowadays
> `smartd` has all the needed filtering features in itself, in a case someone
> gets "annoyed" by attribute changes. Yeah, sure, it "can send warning mails",
> but by default only in a case of attribute FAILURE, and some Old-age related
> attributes NEVER fail (like Power-On Hours on WD, which counts down to 1 and
> just sits happily there, never getting to "failing" 0). In such cases at least
> seeing them changing (or not) is useful. Overall, it's not the place for a
> *maintainer* to decide (instead of a user) which events of a third-party
> package are annoying and which are not.

Following up on the above  bug from 2020 -- we need more information
here: what is the issue that you would like fixed?
you can already (even in 2020) add or subtract any rules for logcheck
that you like. smartd has a way to alert you to issues, but
that is nothing to do with logcheck.

in the absence of a clearer statement we would need to close this one.

Bug#862638: logcheck: Please add suricata rules to logcheck

[Richard Lewis]

control: tags -1 moreinfo
control: severity -1 wishlist
thanks

On Mon, 15 May 2017 10:42:03 +0200

> I am very happy with logcheck. It is great working and very usefull. However, 
> it would be nice, if you could add a ruleset for suricata (a successor to the 
> well known snort IDS), so I get alerted, when something fishy is going on.

It's a shame no-one replied to this bug from 2017 - let's change that now.

>In my case logcheck is run every 30 minutes, so I am very fast aware, when an 
>attack is going on. On the other hand, I found no realtime alert option with 
>suricata. Best way, IMO, would be a ruleset for suricata logs, which do alert 
>me by mail (as logcheck normally do).

Unfortunately more information is needed to help this.

Is the request to use logcheck to scan non-log files created by
suricata? you can definitely do that but would need to write your own
rules to ignore things that are not "fishy".
...but i dont think logcheck-database should ship such rules unless
there is clear demand. It looks like suricata can send its own alerts
so not sure this is even needed in 2024?

If there are messages produced by suricata in the journal that
logcheck should be filtering, then we need to know what those are?

(In the absence of more information we would likely close this bug as
unactionable)

Bug#735287: logcheck: invent conditional logging

[Richard Lewis]

On Tue, 14 Jan 2014 13:33:25 +0100 Arne Wichmann  wrote:

> There is one thing I would like to have in logcheck for quite a long time
> already:
>
> Invent a mechanism by which a pattern is only mailed (or not mailed) if
> another pattern was seen a given time before it (or also possibly after
> it).
>
> For example I would like to make reboots invisible on some machines, but I
> do want to see it if the sshd terminates as long as the machine is not
> rebooting.

Hi - It's a shame no-one replied to this bug in 10 years: let's change that now.

The only realistic way i can see this working is to have some kind of
pre-processing of log entries. I'm thinking you would write a
pre-processor that takes each line in the log
and look back in the journal (or syslog) for related lines -- i dont
think we'd want to implement that in logcheck, as it would be a whole
other project to write, but we could allow
the user to do it. There are several reasons to make logcheck
configurable to pre-processing ( - work on this is in progress. watch
this space!).
You can maybe even today do this with post-processing by writing a
'syslog-summary' script - again this would need the user to write
their own code.

(I think the point in the last para is basically solved by using
systemd, which makes it much easier to restart daemons when they
crash)

In the absence of other suggestions, i suggest we implement
configurable pre-processing, leave syslog-summary support in place and
close this bug.

Bug#919866: logcheck: Feature request: wildcards in .logfiles pathnames

[Richard Lewis]

On Sun, 20 Jan 2019 15:50:55 +0530 Charles Atkinson
 wrote:

> Please consider introducing wildcards into the paths in the .logfiles 
> configuration files.  Perhaps similar to the way they are used in logrotate's 
> paths.

> A use case is when using logcheck to check logs from multiple non-Debian 
> systems such as routers, each having a dedicated directory with the last 
> directory being their FQDN.  The router FQDNs follow a fixed pattern.  
> Currently this requires an /etc/logcheck-for-routers/logcheck.logfile.d file 
> for each router.  If .logfiles supported wildcards, a single 
> /etc/logcheck-for-routers/logcheck.logfile.d file could be used for all 
> routers and there would be one less step in the procedures to commission and 
> to decommission a router.

(It's a shame no-one replied since 2019: let's change that now)

You could instead implement this by a script that updates the
.logfiles file before logcheck runs: if you put this into
logcheck.conf it would work, so eg:

echo /var/log/whatever/*.log >
/etc/logcheck-for-routers/logcheck.logfiles.d/routers.logfiles

If that would meet your needs we could close this bug - the code to
read logfiles.list is already over-complicated and adding more
features needs a good reason

Bug#241787: options to seperate hosts and for log compaction would both be nice

[Richard Lewis]

> This bug is nearly 20 years old. (It is a shame no-one replied - the links
> no longer work and there is not enough info recorded to action)
>
> Unless anyone is watching and can proivde more info about what the issue
> is/was then i suggest we close it.

A year later: closing.

logcheck can send reports as gzip'd attachments so perhaps it was even
fixed sometime in the last 20 years.

Bug#302379: dh_installlogcheck installs files as root:root 644, not root:logcheck 640

[Richard Lewis]

On Mon, 24 Aug 2009 08:36:21 -0400
=?iso-8859-1?B?RnLpZOlyaWMgQnJp6HJl?=  wrote:
> On Thu, Mar 31, 2005 at 09:54:34AM -0500, Marc Sherman wrote:
> > I reported a bug on a couple clamav packages (302253, 302254) which
> > noted that in Sarge, logcheck files are supposed to be root:logcheck
> > 640, not root:root 644.  The clamav maintainer replied that he's using
>
> I should note that while the /etc/logcheck/* directories are setgid to
> attempt to fix this discrepancy, this doesn't work, as dpkg will chown()
> the installed files anyway.
>
> I guess there should be a note in README.Maintainer to instruct people
> not to install those files as 640, as tempting as it may be.

Closing this bug because it no longer applies some 15 years later:
- The directory /etc/logcheck is no longer setgid (since bookworm),
- Rules can have any permissions (as long as logcheck can read them).
  (the default is 644 and  root:root (which means harder to delete rules files).
- so no need for dh_logcheck to be patched here

therefore, closing as no more bug. (But feel free to reopen if there
is anything more to do)

Bug#383289: RFE: logtail locking

[Richard Lewis]

On Wed, 16 Aug 2006 05:33:26 -0500 bingo  wrote:

> It would be good if logtail supports locking.

I think we need some more information if this bug is to be action-ed.
logcheck uses logtail2 now (and syslog is not the default):so perhaps
it is not relevant after nearly 20 years (there were other replies
requesting patches in the intervening period, and no-one has provided
them -- so perhaps we should just close this as no longer relevant).

If the issue is that rsyslog might still be writing to the file, when
logtail runs, surely all that might happen is that the same entries
might be re-checked on the next run?
(and I dont think it would be sensible for logtail to try and stop
rsyslog writing while logtail runs)
the journal has a better way to avoid races, using --cursor-file --
logcheck doesnt yet use that (watch this space!) which i think might
also avoid potential race conditions here

Bug#750232: logtail2 should not not print the final log entry if it does not end with "\n"

[Richard Lewis]

On Mon, 2 Jun 2014 10:25:40 -0700 (PDT) Chris Stromsoe  wrote:

> logtail2 does not do any sanity checking on the final line of input to
> make sure that it is complete and "\n" terminated.  If syslog is not set
> to flush on every write, it's possible for consecutive runs of logcheck to
> get a single log entry split in half for each run, resulting in false
> positives from logcheck.

Is this still an issue in 2024? if not we could close this old bug.

If you ran logtail2 on a non-syslog file (which might actually be an
increasingly common usage in a systemd world?), then ignoring a line
without a trailing \n means that last line might never be checked,
which seems far worse than the occasional false-positive. I dont think
i ever saw such false positives with rsyslog, when i used it.

Bug#470997: logcheck: allow running w/o locking

[Richard Lewis]

On Fri, 14 Mar 2008 21:50:17 -0400 =?utf-8?b?RnLDqWTDqXJpYyBCcmnDqHJl?= <

> When testing a checked-out copy of the rulefiles against an old log copy
> and sending the output to stdout, I still have to use sudo because
> logcheck insists on creating a lockfile.  It'd be nice to provide an
> option to skip that part.

This is easy to solve by changing LOCKDIR to point to something you can access.
You presumably are setting a custom configuration file to run as
non-root (since you wont be able to read /etc/logcheck/logcheck.conf
without sudo), and then
that custom config file can change the location to /tmp or wherever.

I think this already works in the version in bookworm, so perhaps we
can close this bug

Bug#470608: work-around for logcheck email charset

[Richard Lewis]

On Sat, 16 May 2020 17:12:42 -0700 Wade Richards  wrote:
> This is regarding Debian bug #47608 "wrong charset in logcheck mail
> (charset=unknown-8bit)"
>
>
> The maintainer has closed this bug as 'wontfix', but if an end-user is
> looking for a work-around, you can add the following to your
> /etc/logcheck.conf file
>
>
> # Additional args to mime-construct for sending email
>
> MIMECONSTRUCTARGS="$MINECONSTRUCTARGS --type 'text/plain;
> charset=UTF-8'"
>
>
> It's an undocumented option, so it may stop working with a future
> version of logcheck, but it works for now.

logcheck also has an option 'MIMEENCODING=' does that solve this issue?

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Richard Lewis]

On Sat, 18 Mar 2023 18:55:25 + Richard Lewis
 wrote:
> On Sat, 18 Mar 2023, 15:12 Holger Levsen,  wrote:
>
> > On Thu, Mar 16, 2023 at 06:00:06PM +, Holger Levsen wrote:
> > > aaah, thanks! I only checked
> > /usr/share/doc/logcheck/NEWS.Debian.gz
> > > but not /usr/share/doc/logcheck-database/NEWS.Debian.gz
> >
> > now that I read it and followed the advice and the very nice
> > sed example there, I can they that it worked flawlessly and was
> > very easy to do. Thank you for that NEWS entry!
> >
> > > so maybe reassign this bug to src:release-notes?
> >
> > this question is still open... though maybe cloning the bug is even
> > better, I'd really appreciated a small pointer to logcheck-database's NEWS
> > file in the NEWS for logcheck...

Think we may as well close this bug, unless anyone objects. bookworm
release-notes cover the issue.
Next big change im planning to document in logcheck's NEWS.Debian to
catch all users - watch this space!

Bug#583600: ignore individual entries but write summaries

[Richard Lewis]

On Fri, 28 May 2010 19:04:17 +0200 Holger Levsen  wrote:

> I often add logcheck ignore rules for security related events (like ssh login
> attemps. etc), cause they are too many and login is protected reasonably
> anyway.
>
> But then I would like to get summaries for some ignored patterns, probably one
> mail per host day.
>
> Do you think thats a reasonable feature request?

This is already possible, maybe that's why no-one replied for 15
years. Simply create a command called syslog-summary and tell logcheck
to use it (via the setting in logcheck.conf)

Think we should close this bug on that basis

it would be better to develop such a summarising programme outside
logcheck as it's a whole other project to work out what to summarise,
and how to present the results - you'd need a lot of flexibility to
please everyone, i suspect. There was packaged version called
syslog-summary some releases ago, but no-one maintained it and it was
removed from Debian. but the code to use it remains in logcheck.

Bug#1070972: epiphany-browser fails to render webpages - blank pages

[richard]

Package: epiphany-browser
Version: 46.0-2
Severity: important
X-Debbugs-Cc: bug.repor...@mail.sheugh.com

Dear Maintainer,

A previously installed debian system** was reconfigured via 
the intallation of debian-12-5 from a dvd. That 'bookworm'
installation was updated to 'trixie' almost immediately, 
and additional packages, including epiphany-browser and 
konquerer browser were installed. 

On opening epiphany browser, as expected, six webpage tabs 
appeared, however the content of the pages was not rendered. 

These pages appeared to be blank. 

Moving the mouse over the pages showed that the webpage links 
were present. I did not explore further. 

A search on the internet suggested that libwebkitgtk might be 
a source of this problem. 

** prior to the reconfiguration I had saved all the packages 
to a folder. 

In that folder I ran 
# sudo dpkg -i ./libwebkitgtk*
 
This reported 
dpkg: warning: downgrading libwebkitgtk-6.0-4:amd64 from 2.44.1-1+b1 to 2.42.5-1

 libwebkitgtk-6.0-4:amd64 depends on libjavascriptcoregtk-6.0-1 (= 2.42.5-1);

I ran 
sudo dpkg -i ./libwebkitgtk* ./libjavascriptcoregtk-6.0-1*

And got 
(Reading database ... 158748 files and directories currently installed.)
Preparing to unpack .../libwebkitgtk-6.0-4_2.42.5-1_amd64.deb ...
Unpacking libwebkitgtk-6.0-4:amd64 (2.42.5-1) over (2.42.5-1) ...
dpkg: warning: downgrading libjavascriptcoregtk-6.0-1:amd64 from 2.44.1-1+b1 to 
2.42.5-1
Preparing to unpack .../libjavascriptcoregtk-6.0-1_2.42.5-1_amd64.deb ...
Unpacking libjavascriptcoregtk-6.0-1:amd64 (2.42.5-1) over (2.44.1-1+b1) ...
Setting up libjavascriptcoregtk-6.0-1:amd64 (2.42.5-1) ...
Setting up libwebkitgtk-6.0-4:amd64 (2.42.5-1) ...
Processing triggers for libc-bin (2.38-7) ...

The pages now appear as they should. 

HTH


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages epiphany-browser depends on:
hi  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
hi  epiphany-browser-data 46.0-2
hi  gsettings-desktop-schemas 46.0-1
hi  iso-codes 4.16.0-1
hi  libadwaita-1-01.5.0-1
hi  libarchive13t64   3.7.2-2
hi  libc6 2.38-7
hi  libcairo2 1.18.0-3+b1
hi  libgck-2-24.2.0-5
hi  libgcr-4-44.2.0-5
hi  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b3
hi  libglib2.0-0t64   2.80.1-1
hi  libgmp10  2:6.3.0+dfsg-2+b1
hi  libgranite-7-77.4.0-1+b2
hi  libgraphene-1.0-0 1.10.8-3+b1
hi  libgstreamer1.0-0 1.24.3-1
hi  libgtk-4-14.12.5+ds-6+b1
hi  libhogweed6t643.9.1-2.2
ii  libjavascriptcoregtk-6.0-12.42.5-1
hi  libjson-glib-1.0-01.8.0-2+b1
hi  libnettle8t64 3.9.1-2.2
hi  libpango-1.0-01.52.2+ds-1
hi  libportal-gtk4-1  0.7.1-5+b1
hi  libportal10.7.1-5+b1
hi  libsecret-1-0 0.21.4-1+b1
hi  libsoup-3.0-0 3.4.4-5+b1
hi  libsqlite3-0  3.45.3-1
ii  libwebkitgtk-6.0-42.42.5-1
hi  libxml2   2.9.14+dfsg-1.3+b3

Versions of packages epiphany-browser recommends:
hi  ca-certificates  20240203
hi  evince   46.0-1+b1
hi  yelp 42.2-1+b2

epiphany-browser suggests no packages.

-- no debconf information

Bug#1070717: Acknowledgement (linux-image-6.7.12-amd64: Mediatek mt7921e WiFi fails connecting after hibernation since 6.7.12)

[Richard Rosner]

Addendum: this is the output of dmesg related to mt7921e that shows up
when this happens:

[Th May  9 18:36:50 2024] mt7921e :01:00.0:
firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7922_1.bin
[Th May  9 18:36:50 2024] mt7921e :01:00.0: ASIC
revision: 79220010
[Th May  9 18:36:50 2024] mt7921e :01:00.0:
firmware: direct-loading firmware mediatek/WIFI_MT7922_patch_mcu_1_1_hdr.bin
[Th May  9 18:36:50 2024] mt7921e :01:00.0: HW/SW
Version: 0x8a108a10, Build Time: 20230530123154a
[Th May  9 18:36:50 2024] mt7921e :01:00.0:
firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7922_1.bin
[Th May  9 18:36:50 2024] mt7921e :01:00.0: WM
Firmware Version: 00, Build Time: 20230530123236
[Th May  9 18:36:50 2024] mt7921e :01:00.0:
firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7922_1.bin
[Th May  9 18:36:51 2024] mt7921e :01:00.0 wlp1s0:
renamed from wlan0
[Fr May 10 09:53:01 2024] mt7921e :01:00.0: Message
00020007 (seq 8) timeout
[Fr May 10 09:53:01 2024] mt7921e :01:00.0: PM:
dpm_run_callback(): pci_pm_restore+0x0/0xe0 returns -110
[Fr May 10 09:53:01 2024] mt7921e :01:00.0: PM:
failed to restore async: error -110
[Fr May 10 09:53:01 2024] mt7921e :01:00.0: Failed
to get patch semaphore
[Fr May 10 09:53:01 2024] mt7921e :01:00.0: AMD-Vi:
Event logged [IO_PAGE_FAULT domain=0x000d address=0xffcec680 flags=0x]
[Fr May 10 09:53:04 2024] mt7921e :01:00.0: Message
0010 (seq 6) timeout
[Fr May 10 09:53:04 2024] mt7921e :01:00.0: Failed
to get patch semaphore
[Fr May 10 09:53:07 2024] mt7921e :01:00.0: Message
0010 (seq 7) timeout
[Fr May 10 09:53:07 2024] mt7921e :01:00.0: Failed
to get patch semaphore
[Fr May 10 09:53:10 2024] mt7921e :01:00.0: Message
46ed (seq 8) timeout
[Fr May 10 09:53:10 2024] Modules linked in: snd_usb_audio
snd_usbmidi_lib snd_rawmidi tls uinput ctr ccm rfcomm cmac algif_hash
algif_skcipher af_alg snd_seq_dummy snd_hrtimer snd_seq snd_seq_device
nf_tables typec_displayport qrtr bnep zstd zram tun binfmt_misc
nls_ascii nls_cp437 vfat fat btusb btrtl btintel btbcm btmtk
intel_rapl_msr intel_rapl_common bluetooth evdev joydev
snd_sof_amd_rembrandt snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp
snd_hda_codec_realtek snd_sof sha3_generic snd_hda_codec_generic
jitterentropy_rng mt7921e snd_sof_utils mt7921_common
ledtrig_audio uvcvideo edac_mce_amd mt792x_lib snd_hda_codec_hdmi
snd_soc_core drbg mt76_connac_lib videobuf2_vmalloc uvc kvm_amd
videobuf2_memops ansi_cprng snd_compress snd_hda_intel videobuf2_v4l2
mt76 snd_pcm_dmaengine hid_sensor_als videodev snd_intel_dspcfg
hid_sensor_trigger ecdh_generic snd_intel_sdw_acpi ecc
hid_sensor_iio_common snd_pci_ps kvm mac80211 snd_hda_codec crc16
videobuf2_common industrialio_triggered_buffer kfifo_buf
snd_rpl_pci_acp6x irqbypass
[Fr May 10 09:53:10 2024] mt7921e :01:00.0: AMD-Vi:
Event logged [IO_PAGE_FAULT domain=0x000d address=0xff772a80 flags=0x]
[Fr May 10 09:53:10 2024] Modules linked in: snd_usb_audio
snd_usbmidi_lib snd_rawmidi tls uinput ctr ccm rfcomm cmac algif_hash
algif_skcipher af_alg snd_seq_dummy snd_hrtimer snd_seq snd_seq_device
nf_tables typec_displayport qrtr bnep zstd zram tun binfmt_misc
nls_ascii nls_cp437 vfat fat btusb btrtl btintel btbcm btmtk
intel_rapl_msr intel_rapl_common bluetooth evdev joydev
snd_sof_amd_rembrandt snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp
snd_hda_codec_realtek snd_sof sha3_generic snd_hda_codec_generic
jitterentropy_rng mt7921e snd_sof_utils mt7921_common
ledtrig_audio uvcvideo edac_mce_amd mt792x_lib snd_hda_codec_hdmi
snd_soc_core drbg mt76_connac_lib videobuf2_vmalloc uvc kvm_amd
videobuf2_memops ansi_cprng snd_compress snd_hda_intel videobuf2_v4l2
mt76 snd_pcm_dmaengine hid_sensor_als videodev snd_intel_dspcfg
hid_sensor_trigger ecdh_generic snd_intel_sdw_acpi ecc
hid_sensor_iio_common snd_pci_ps kvm mac80211 snd_hda_codec crc16
videobuf2_common industrialio_triggered_buffer kfifo_buf
snd_rpl_pci_acp6x irqbypass
[Fr May 10 09:53:14 2024] mt7921e :01:00.0: Message
0010 (seq 9) timeout
[Fr May 10 09:53:14 2024] mt7921e :01:00.0: Failed
to get patch semaphore
[Fr May 10 09:53:14 2024] mt7921e :01:00.0: AMD-Vi:
Event logged [IO_PAGE_FAULT domain=0x000d address=0xffd79900 flags=0x]
[Fr May 10 09:53:14 2024] mt7921e :01:00.0: AMD-Vi:
Event logged [IO_PAGE_FAULT domain=0x000d address=0xffd79900 flags=0x]
[Fr May 10 09:53:14 2024] mt7921e :01:00.0: AMD-Vi:
Event logged [IO_PAGE_FAULT domain=0x000d 

Bug#1063900: gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)

[Richard B]

Hello.

Upgrading gstreamer1.0-plugins-ugly to 1.24.3-1 on Trixie didn't produce 
the error that was originally reported.  Here's my output:


   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   serious bugs of gstreamer1.0-plugins-good (1.22.10-1 → 1.24.3-1)
   
 b1 - #1063900 - gstreamer1.0-plugins-good: missing
   Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)
   Merged with: 1063921
   Summary:
 gstreamer1.0-plugins-good(1 bug)
   Are you sure you want to install/upgrade the above packages?
   [Y/n/?/...] y
   Reading changelogs... Done
   ...
   Preparing to unpack .../gstreamer1.0-plugins-good_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-good:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack .../gstreamer1.0-plugins-bad_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-bad:amd64 (1.24.3-1) over (1.22.10-1) ...
   ...
   Preparing to unpack
   .../04-libgstreamer-plugins-bad1.0-0_1.24.3-1_amd64.deb ...
   Unpacking libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack
   .../05-gir1.2-gst-plugins-bad-1.0_1.24.3-1_amd64.deb ...
   Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   ...
   Setting up libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) ...
   Setting up gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-good:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-bad:amd64 (1.24.3-1) ...
   Processing triggers for libc-bin (2.38-7) ...

I see that the conflicting files mentioned are on my system, but that 
didn't seem to impact my upgrade:


   -rw-r--r-- 1 root root 27K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
   -rw-r--r-- 1 root root 19K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
   -rw-r--r-- 1 root root 208 Apr 29 18:15
   /usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs

gstreamer1.0-plugins-ugly was upgraded to a matching version before 
this.  Here's what dpkg reports:


   ii  gstreamer1.0-plugins-ugly:amd64
   1.24.3-1 amd64    GStreamer plugins
   from the "ugly" set

Best.

Richard

Bug#1049972: Upstream issue

[Richard van der Hoff]

For links, this seems to be 
https://github.com/rdiff-backup/rdiff-backup/issues/616. Apparently it's 
expected behaviour.

Bug#1070717: linux-image-6.7.12-amd64: Mediatek mt7921e WiFi fails connecting after hibernation since 6.7.12

[Richard Rosner]

uot; operation="open" class="file"
profile="libreoffice-soffice"
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max"
pid=6388 comm=433120436F6D70696C657254687265 requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[  435.827462] kauditd_printk_skb: 23 callbacks suppressed
[  435.827471] audit: type=1400 audit(1715094303.003:543):
apparmor="ALLOWED" operation="open" class="file"
profile="libreoffice-soffice"
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max"
pid=6388 comm=433120436F6D70696C657254687265 requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[  438.120605] audit: type=1400 audit(1715094305.295:544):
apparmor="ALLOWED" operation="open" class="file"
profile="libreoffice-soffice"
name="/home/richard/.config/LanguageTool/LibreOffice/LanguageTool.log"
pid=6388 comm="soffice.bin" requested_mask="ac" denied_mask="ac"
fsuid=1000 ouid=1000
[  438.120658] audit: type=1400 audit(1715094305.295:545):
apparmor="ALLOWED" operation="file_perm" class="file"
profile="libreoffice-soffice"
name="/home/richard/.config/LanguageTool/LibreOffice/LanguageTool.log"
pid=6388 comm="soffice.bin" requested_mask="w" denied_mask="w"
fsuid=1000 ouid=1000
[  804.953714] i2c_hid_acpi i2c-FRMW0003:00: i2c_hid_get_input:
incomplete report (7/65535)
[ 1121.046255] usb 1-4.1: reset full-speed USB device number 7 using
xhci_hcd
[ 1121.265790] usb 1-4.1: reset full-speed USB device number 7 using
xhci_hcd
[ 2531.546014] usb 1-2.1: new high-speed USB device number 9 using xhci_hcd
[ 2531.683091] usb 1-2.1: New USB device found, idVendor=32ac,
idProduct=0010, bcdDevice= 0.02
[ 2531.683100] usb 1-2.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 2531.683104] usb 1-2.1: Product: Audio Expansion Card
[ 2531.683107] usb 1-2.1: Manufacturer: Framework
[ 2531.742937] input: Framework Audio Expansion Card Consumer Control as
/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/1-2.1/1-2.1:1.2/0003:32AC:0010.0008/input/input18
[ 2531.802301] hid-generic 0003:32AC:0010.0008: input,hidraw7: USB HID
v1.11 Device [Framework Audio Expansion Card] on usb-:c1:00.3-2.1/input2
[ 2532.064766] usbcore: registered new interface driver snd-usb-audio
[ 2532.085724] input: Framework Audio Expansion Card Consumer Control as
/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/1-2.1/1-2.1:1.2/0003:32AC:0010.0009/input/input19
[ 2532.142241] hid-generic 0003:32AC:0010.0009: input,hidraw7: USB HID
v1.11 Device [Framework Audio Expansion Card] on usb-:c1:00.3-2.1/input2
[ 2540.147902] MediaPD~oder #1[62983]: segfault at 60 ip
7fe017d0b2dd sp 7fe038ffce20 error 4 in
libLLVM-16.so.1[7fe01520+6d26000] likely on CPU 15 (core 7, socket 0)
[ 2540.147919] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24
40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24
48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49
[ 2578.200646] MediaPD~oder #1[64518]: segfault at 60 ip
7fe016b0b2dd sp 7fe03a367e20 error 4 in
libLLVM-16.so.1[7fe01400+6d26000] likely on CPU 5 (core 2, socket 0)
[ 2578.200671] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24
40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24
48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49
[ 2959.977573] MediaPD~oder #1[81449]: segfault at 60 ip
7fe01750b2dd sp 7fe03a367e20 error 4 in
libLLVM-16.so.1[7fe014a0+6d26000] likely on CPU 2 (core 1, socket 0)
[ 2959.977598] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24
40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24
48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49
[ 2974.055589] MediaPD~oder #2[81490]: segfault at 60 ip
7fe012f0b2dd sp 7fe038efce20 error 4 in
libLLVM-16.so.1[7fe01040+6d26000] likely on CPU 8 (core 4, socket 0)
[ 2974.055603] Code: fe eb 02 31 c0 48 89 44 24 10 4d 85 f6 4c 89 74 24
40 48 89 6c 24 38 74 0a 4c 89 f7 e8 3c 7f 32 fe eb 02 31 c0 48 8b 54 24
48 <48> 8b 6a 60 48 85 ed 0f 84 a8 00 00 00 0f b6 4c 24 0f 41 88 cd 49
[ 3208.859075] audit: type=1400 audit(1715097075.994:546):
apparmor="DENIED" operation="open" class="file"
profile="torbrowser_firefox"
name="/usr/local/lib/x86_64-linux-gnu/libEGL.so.1.0.0" pid=87874
comm="glxtest" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 3208.861128] audit: type=1400 audit(1715097075.994:547):
apparmor="DENIED" operation="open" class=&quo

Bug#1070671: Please include static library builds in libharfbuzz-dev

[Daniel Richard G.]

Package: libharfbuzz-dev
Version: 8.3.0-2+b1

It is customary for -dev packages to provide static archive libraries in
addition to the bare .so files for shared-library linking. The current
version of libharfbuzz-dev only provides the latter, and thus does not
allow applications to statically link the libraries.

I understand that GObject introspection requires a shared-library build,
but this functionality is often not needed. In particular, the Chromium
browser consumes harfbuzz and harfbuzz-subset, and does perfectly well
without introspection support. I recently ran into a situation on the
Ubuntu side of things where the lack of a static-linking option caused
some difficulty in supporting Chromium on 22.04/jammy:

https://bugs.launchpad.net/bugs/2064821

My solution was to produce a modified harfbuzz package that provides
(only) static libraries:


https://launchpad.net/~xtradeb/+archive/ubuntu/deps/+sourcepub/16120809/+listing-archive-extra

Needless to say, it would be preferable if the official packages
supported static linking from the get-go.

Bug#1070669: Please include a static library build in libdav1d-dev

[Daniel Richard G.]

Package: libdav1d-dev
Version: 1.4.1-1

It is customary for -dev packages to provide a static archive library in
addition to the bare .so file for shared-library linking. The current
version of libdav1d-dev only provides the latter, and thus does not
allow applications to statically link the library.

Bug#1070483: btrfs root volume being mounted as ro upon boot

[Richard Rosner]

Package: installation-reports

Severity: important


Boot method: USB stick
Image version:
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-gnome.iso
Date: 19.04.2024

Machine: Framework 16
Processor: AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
Memory: 2 x 16 GB Crucial DDR5 5600MHz
Partitions: from lsblk:

NAME  MAJ:MIN RM  SIZE RO TYPE 
MOUNTPOINTS
zram0 252:0    0  8,2G  0 disk 
[SWAP]
nvme0n1   259:0    0  3,6T  0 disk
├─nvme0n1p1   259:1    0    2G  0 part 
/boot/efi
├─nvme0n1p2   259:2    0   35G  0 part
│ └─luks-  253:1    0 35G  0 crypt [SWAP]
└─nvme0n1p3  259:3    0  3,6T  0 part
  └─luks-   253:0    0 3,6T  0 crypt
/home
/

Output of lspci -knn (or lspci -nn):

00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14e8]
    Subsystem: Framework Computer Inc. Device [f111:0005]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device [1022:14e9]
    Subsystem: Framework Computer Inc. Device [f111:0005]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14ea]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14ea]
00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14ee]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453]
    Kernel driver in use: pcieport
00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14ee]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453]
    Kernel driver in use: pcieport
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14ea]
00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 19h
USB4/Thunderbolt PCIe tunnel [1022:14ef]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453]
    Kernel driver in use: pcieport
00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14ea]
00:04.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 19h
USB4/Thunderbolt PCIe tunnel [1022:14ef]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:1453]
    Kernel driver in use: pcieport
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14ea]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14eb]
    Subsystem: Device [0005:f111]
    Kernel driver in use: pcieport
00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14eb]
    Subsystem: Device [0005:f111]
    Kernel driver in use: pcieport
00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14eb]
pcilib: Error reading /sys/bus/pci/devices/:00:08.3/label: Operation
not permitted
    Subsystem: Device [0005:f111]
    Kernel driver in use: pcieport
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:790b] (rev 71)
    Subsystem: Framework Computer Inc. Device [f111:0005]
    Kernel driver in use: piix4_smbus
    Kernel modules: i2c_piix4, sp5100_tco
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC
Bridge [1022:790e] (rev 51)
    Subsystem: Framework Computer Inc. Device [f111:0005]
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f0]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f1]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f2]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f3]
    Kernel driver in use: k10temp
    Kernel modules: k10temp
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f4]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f5]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f6]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:14f7]
01:00.0 Network controller [0280]: MEDIATEK Corp. MT7922 802.11ax PCI
Express Wireless Network Adapter [14c3:0616]
    Subsystem: MEDIATEK Corp. Device [14c3:e616]
    Kernel driver in use: mt7921e
    Kernel modules: mt7921e
02:00.0 Non-Volatile memory controller [0108]: Sandisk Corp WD Black
SN850X NVMe SSD [15b7:5030] (rev 01)
    Subsystem: Sandisk Corp WD Black SN850X NVMe SSD [15b7:5030]
    Kernel driver in use: nvme
    Kernel modules: nvme
c1:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Phoenix1 [1002:15bf] (rev c2)
    Subsystem: Framework Computer Inc. Device [f111:0005]
    Kernel driver in use: amdgpu
    Kernel modules: amdgpu
c1:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
Rembrandt Radeon High Definition Audio Controller [1002:1640]
    Subsystem: Framework Computer Inc. Device [f111:0005]

Bug#1070281: logcheck: becomes less and less usable because of user-level logs

[Richard Lewis]

On Fri, 3 May 2024, 12:44 Francesco Potortì,  wrote:

>
> > One cure would be to have logcheck ignore user-level messages, and only
> care about system-level ones.  Is that possible?
> >
> >maybe it is possible - how do you define "system-level message"?
>
> Those created by root-owned processes, that would be a good start.  I
> definitely care about Sshd messages, much less about Gvfsd ones, and even
> less by those generated by Telegram running over Snapd.  For some reason,
> the problem has vastly increased after the advent of systemctl.



The options seem to be

1.you make a local rule that ignores all messages from known culprets  --
so you might jusy want to do a version of
"^timestamp hostname (Telegram|gvfsd)". This works today, but does need you
to know what you want to ignore


2.you tell logcheck to.not check the journal at all - also possoble today:
simply remove "journal" from the file in /etc/logcheck/logcheck.logfiles.d
(i dont know if this is that helpful!)

3. i have work in progress to allow you to tell logcheck to only check a
subset of the journal by passif  arguments to journalctl. Looking at the
journalctl.man-page:
 --unit ssh.service will only show messages from ssh
eg --system might exclude things  like telegram (untested!)
eg --priority might also be helpful
eg _UID=0 might select only things run by root (but that would probably
exclude things run by special users like apache)
eg --priority might also help?

This needs a small change in logcheck to make JOURNALCTL_OPTS settable from
the config file - this is WiP already! (logcheck currently hardcoded this
to an empty array)

other thoughts:
- we could definitely make logcheck only report the first N lines. I can
broadly see how to implement this. you can almost do this today by making a
"syslog-summary" script!

Bug#1070436: autopkgtest-virt-schroot: error when using 'unshare --net' even though schroot allows this

[Richard Lewis]

control: close 1070436
thanks

On Sun, 5 May 2024, 19:10 Jochen Sprickerhof,  wrote:

> Hi Richard,
>
> * Richard Lewis  [2024-05-05 11:32]:
> >If i try and run tests that use 'unshare --net' with a
> >schroot backend they fail inside autopkgtest even though
> >this works in the schroot being used.
> >
> >This works fine in a 'plain schroot' (I expect i allowed
> >the calling user to run the schroot as root in the schroot
> >in /etc/schroot):
> >
> > $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user
> root -- unshare --net --map-root-user ls
> > bin  boot  build  dev  etc  home  lib  lib64  media  mnt  opt  proc
> root  run  sbin  srv  sys  tmp  usr  var
>
> I can't reproduce this. Testing in a fresh debvm:
>
> $ debvm-create --size=2G --release=stable -- \
>  --include=sbuild,schroot,debootstrap,autopkgtest \
>  --hook-dir=/usr/share/mmdebstrap/hooks/useradd
> $ debvm-run
> # echo "inside debvm"
> # sbuild-createchroot unstable /srv/chroot/unstable-amd64-sbuild \
>  http://deb.debian.org/debian
> # sbuild-adduser user
> # su - user
> $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root
> -- unshare --net --map-root-user ls
> unshare: unshare failed: Operation not permitted
>
> Do you have any idea why it works for you?
>

im so sorry - this was just a complete user error by me.

 the issue is the --map-root-user, i thought absolutely sure i was using
that with plain schroot, but it turns out i was completely misreading what
i was running, and apparently copied the command and output from separate
places.


as you say, if i omit map-root-user then it works with both schroot and
autopkgtest. and if i include map-root-user then both fail.


Over all I think using unshare --map-root-user in
>
autopkgtest-virt-schroot is not supported and I don't think there is a
> way around that except using a different autopkgtest backend.


thanks - this is fair enough.

thanks for the response. and sorry for the noise

Bug#1070440: mesa-va-drivers: vaapi cannot find target for triple amdgcn

[Richard]

Package: mesa-va-drivers
Version: 24.0.6-1+b1
Severity: important

Dear Maintainer,
I'm not sure if this is the right package to report this issue to, as there
recently have been many package updates due to the time_t transition. But mpv,
VLC and Firefox are no longer able to access VA-API while ffmpeg shows stranger
behavior. I can't say for sure when this breakage happened since Firefox is
gracefully falling back to software decoding and I rarely use mpv or VLC, which
just fail to start (even though mpv has the option hwdec=auto-safe set which
should cause the same behavior as in Firefox.

mpv gives this quite ominous error message:

Cannot load libcuda.so.1
Cannot find target for triple amdgcn-- Unable to find target for this triple
(no targets are registered)
Segmentation fault

That it can't load anything Nvidia related is no surprise, I'm on an AMD Ryzen
7 7840HS without any dGPU. Firmware is installed directly from kerne.org as the
one in Debians repos is way too old.

VLC goes into a little more detail:

libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_20
Cannot find target for triple amdgcn-- Unable to find target for this triple
(no targets are registered)
Segmentation fault

Firefox is even more verbose:

[RDD 9113: MediaSupervisor #1]: D/FFmpegVideo FFVPX:
FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/av1 Codec ID 226
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Initialising VA-API FFmpeg
decoder
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   codec av1 : Alliance for
Open Media AV1
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:
FFmpegVideoDecoder::GetAcceleratedFormats()
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Profile
H264ConstrainedBaseline:
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format p010le
3 15
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Profile H264Main:
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format p010le
3 15
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Profile H264High:
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec h264 format p010le
3 15
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Profile VP9Profile0:
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec vp9 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Profile VP9Profile2:
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec vp9 format p010le
3 15
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: vp9 target pixel format
is not supported!
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Profile AV1Profile0:
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format p010le
3 15
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format nv12
3 12
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec av1 format p010le
3 15
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Supported accelerated
formats:
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   h264
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   vp9
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   av1
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   VA-API FFmpeg init
successful
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: FFmpegDataDecoder: shutdown
[RDD 9113: MediaSupervisor #1]: D/FFmpegVideo FFVPX:
FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/av1 Codec ID 226
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Initialising VA-API FFmpeg
decoder
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   Format av1 is accelerated
[RDD 9113: MediaPDecoder #1]: D/FFmpegVideo FFVPX:   codec av1 : Alliance for
Open Media AV1
[AVHWDeviceContext @ 0x7f5a31931340] Format 0x3231564e -> nv12.
[AVHWDeviceContext @ 0x7f5a31931340] Format 0x30313050 -> p010le.
[AVHWDeviceContext @ 0x7f5a31931340] Format 0x36313050 -> unknown.
[AVHWDeviceContext @ 0x7f5a31931340] Format 0x30323449 -> yuv420p.
[AVHWDeviceContext @ 0x7f5a31931340] Format 0x32315659 -> 

Bug#1070436: autopkgtest-virt-schroot: error when using 'unshare --net' even though schroot allows this

[Richard Lewis]

Package: autopkgtest
Version: 5.28
Severity: normal
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

If i try and run tests that use 'unshare --net' with a
schroot backend they fail inside autopkgtest even though
this works in the schroot being used.

This works fine in a 'plain schroot' (I expect i allowed
the calling user to run the schroot as root in the schroot
in /etc/schroot):

 $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root -- 
unshare --net --map-root-user ls
 bin  boot  build  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run 
 sbin  srv  sys  tmp  usr  var

But if i have an autopkgtest with eg a debian/tests/control with

 Test-Command: unshare --map-root-user --net ./debian/tests/foo
 Depends: @
 Features: test-name=foo
 Restrictions: needs-root

then even adding '--user root' doesnt work:

 $ /usr/bin/autopkgtest package.changes --user root -- schroot 
unstable-amd64-sbuild
 
i get errors like

 unshare: unshare failed: Operation not permitted

Same if i put the unshare call inside the test
What am I doing wrong?




-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-17-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   2.6.1
ii  libdpkg-perl1.21.22
ii  procps  2:4.0.2-3
ii  python3 3.11.2-1+b1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.31-1.2

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
ii  lxc  1:5.0.2-1+deb12u2
pn  lxd  
pn  ovmf 
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.5+deb12u1
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
pn  qemu-system  
ii  qemu-utils   1:7.2+dfsg-7+deb12u5
ii  schroot  1.6.13-3+b2
ii  util-linux   2.38.1-5+deb12u1
pn  vmdb2
pn  zerofree 

-- no debconf information

Bug#1070281: logcheck: becomes less and less usable because of user-level logs

[Richard Lewis]

control: reassign -1 logcheck-database
thanks
(this is mostly about logcheck-database)

On Fri, 3 May 2024, 09:39 Francesco Potortì,  wrote:

>
>
> Starting maybe a couple years ago, logcheck spits an amount of stuff that
> has now become unamnageable.


logcheck-database was mostly dormant sround that time. im hoping to improve
that, but it is a big task and needs some wider improvements. So: please
bear with it!


While in the beginning logs were relevant to the system, which is what I
> want, now any bug in a user-level daemon writing info to the syslog or to
> the systemsctl thing makes havoc.


i sympathise


 however:
- a bug in a daemon should ideally be reported and fixed in the daemon
- this may include logging "too much" -- i would suggest discussing with
upstream as they may be open to improvements
- you didnt give any examples so not sure how anyone can help you



I had many email tens of megabytes long.


(there's already a request to split the report if it is long)

  In the last month, reports have been completely useless to me as they are
> filled with useless things and I am busy adding local rules to remove them
>
> Now I have reached a point where its usefulness is negative: I spend more
> time adding rules than it is worth for me getting the info.
>

i sympathise - but writing local rules is always going to be needed. i
think we can do much better than what we have, but realistically it is hard
to do in this way.


If.you wanted to chamge the world, get upstream authors to agree some
standard where messges are easier to identify as routine and then logcheck
could more easily ignore that.   i wont hold my breath for thay



> One cure would be to have logcheck ignore user-level messages, and only
> care about system-level ones.  Is that possible?
>

maybe it is possible - how do you define "system-level message"?

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Richard Lewis]

On Thu, 2 May 2024, 03:45 Vincent Lefevre,  wrote:

> On 2024-05-01 19:05:06 +0100, Richard Lewis wrote:
> > I agree that you should be able to filter out duplicate lines. And i
> think
> > this is possible with a  custom filter.
>
> Yes, but "sed" may not be the best tool for that. With sed, removing
> lines containing only the usual network managers is easier.
>

you dont have to use sed, you can set anything. id use awk or sort.
but then you dont know if things have disappeared.



> > I dont think it should be the default - most chkrootkit users have a more
> > static network setup,
>
> If they have a static network setup, why hiding the interface name?
>

i believe this was because if you have multiple interfaces they may not
have static names (in the days where these were eth0 vs eth1 ) and because
eg dhcpcd was set up to listen on eth0 and wlan0 even if eth0 wasnt used.
maybe some of these assumptions are out of date?

Doing that makes the output more confusing, and the replacement of
> an interface by another one would not be detected.
>
> > and the alert shows something has changed. For laptops where
> > networking is more dynamic it's hard to design something that works
> > for everyone without also hiding information for other people.
>
> But are lines containing *only* the usual network managers suspicious?


no, but it is suspicious is anything changed.

Please also see the manpage which tells you how to use -s to remove these
lines. The config file can easily be used to use -s each time.

Bug#1015201: logcheck: Update patterns, here: rsyslogd

[Richard Lewis]

lOn Mon, 29 Apr 2024, 14:19 Helge Kreutzmann,  wrote:

> Am Sat, Apr 27, 2024 at 07:11:40PM +0100 schrieb Richard Lewis:
> > On Sun, 17 Jul 2022 17:28:11 +0100 Richard Lewis
> >  wrote:
>
> > Hi Helge. Apologies no-one has replied to this bug report for 2 years
> > and that this response isnt going to be what you want!
>
> Thanks for taking care of it anyhow, I noticed that it is not worth
> reporting improvements to logcheck proper.
>

i hope to convince you otherwise! pleae report issues again!

>
> > debian usually doesnt add rules to filter startup messages as it tends
> > to add a lot of rules
>
> Indeed, startup rules are quite helpful, because then I see what was
> *different* during startup, i.e. if something got wrong.


totally agree

For servers,
> this is not very useful, but for workstatins it is. Btw., the current
> rules also deal with startup:
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: imklog [0-9.]+, log source =
> /proc/kmsg started.$
>

i think that practice and theory have diverged here! or possibly this
is/was produced when logs are rotated.

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Richard Lewis]

On Wed, 1 May 2024, 00:57 Vincent Lefevre,  wrote:

> On 2024-05-01 01:29:10 +0200, Vincent Lefevre wrote:
> > For instance, /var/log/chkrootkit/log.expected contains
> >
> > WARNING: Output from ifpromisc:
> > lo: not promisc and no packet sniffer sockets
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> >
> > But /var/log/chkrootkit/log.today currently has a duplicate line:
> >
> > WARNING: Output from ifpromisc:
> > lo: not promisc and no packet sniffer sockets
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> > : PACKET
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> >
> > which has the effect to generate an alert.
>
> This is actually due to the filter in /etc/chkrootkit/chkrootkit.conf,
> which obfuscates the output.
>
> The unfiltered output:
>
> lo: not promisc and no packet sniffer sockets
> eth0: PACKET SNIFFER(/usr/sbin/NetworkManager[1261])
> wlp0s20f3: PACKET SNIFFER(/usr/sbin/NetworkManager[1261],
> /usr/sbin/wpa_supplicant[1263])
>
> But for a laptop, there is not always an Ethernet cable plugged in.
>
> IMHO, known packet sniffers should be filtered out.
>

I agree that you should be able to filter out duplicate lines. And i think
this is possible with a  custom filter.


I dont think it should be the default - most chkrootkit users have a more
static network setup, and the alert shows something has changed. For
laptops where networking is more dynamic it's hard to design something that
works for everyone without also hiding information for other people.

I think the defaults need to be conservative, while allowing people to hide
what they want.

Maybe the best solution is to provide more docs/examples about how to hide
duplicate lines.

Bug#1068161: Video playback regression

[Daniel Richard G.]

Hi Andres,

On Tue, 2024 Apr 30 02:42-04:00, Andres Salomon wrote:
> Please let me know if this is still broken with chromium 124.

I'm happy to report that the issue appears to be resolved in the current
124.0.6367.78-1~deb12u1. (I did not test 124.0.6367.60.)

Some additional info that I meant to send in earlier:

* I was able to work around the problem in 123 with "--use-gl=egl".
  Even now, with 124, I get "MESA: error: Out of instructions"
  messages on the terminal when this flag is removed (but video now
  works either way).

* The video adapter is listed as a "VGA compatible controller [0300]:
  Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
  Graphics Controller [8086:27a2]", on a Lenovo ThinkPad.

* This is a different and much older bug, but I've observed that some
  Web sites show visual artifacts in chromium on this particular system,
  and --use-gl=egl also cleared those up. I think the issue may be that
  the driver for this specific hardware is buggy, and affected users are
  better off using the alternate GL implementation. (I can provide more
  details if this is of interest.)

Bug#1070109: fakechroot: apt crashes inside fakechroot

[Richard Ulrich]

Package: fakechroot
Version: 2.20.1+ds-17
Severity: important
X-Debbugs-Cc: ri...@paraeasy.ch

Dear Maintainer,

We use fakechroot for building a live OS that starts out with debootstrap. This 
worked fine for a while, but started to fail last week. Now apt crashes when it 
ties to download anything:
https://github.com/AminaBank/livedeb/blob/master/Dockerfile#L85
 => ERROR [stage-8  4/30] RUN fakechroot chroot ROOTFS apt-get update  && 
fakechroot chroot ROOTFS a  1.2s 
--  
   
 > [stage-8  4/30] RUN fakechroot chroot ROOTFS apt-get update  && fakechroot 
 > chroot ROOTFS apt-get -y dist-upgrade  && fakechroot chroot ROOTFS apt-get 
 > install -y --no-install-recommends curldosfstools electrum fdisk 
 >   firefox-esr fonts-freefont-ttf  fonts-noto-mono keepassxc  
 >  libgl1  libglib2.0-0libykpiv2   minicom mousepad
 > mtools  openssh-client  p7zip-full pcscdpython3-pyqt5   
 > systemd-resolvedsystemd-timesyncd   thunar-archive-plugin   
 > xarchiver xfce4 xfce4-terminal  xinit   xserver-xorg
 > yubikey-manager:
#9 0.613 Reading package lists...
#9 1.059 E: Method http has died unexpectedly!
#9 1.059 E: Sub-process http received a segmentation fault.
#9 1.059 E: Method /usr/lib/apt/methods/http did not start correctly
#9 1.059 E: Failed to fetch 
http://deb.debian.org/debian/dists/bookworm/InRelease  
#9 1.059 E: Some index files failed to download. They have been ignored, or old 
ones used instead.

I don't know where the problem really lies, but when I buil an older version, 
where fakechroot was not used, then it builds just fine:
https://github.com/AminaBank/livedeb/blob/b38de278e45f0175f5d9c5fc39716a4e31eda6c3/Dockerfile#L37
 

The first version that uses fakechroot generates a slightly different error 
messages, but also at about the same place:
https://github.com/AminaBank/livedeb/blob/e22eda84c67643da13d46cb56a24e1eb47fdbfcd/Dockerfile#L57
Step 11/50 : RUN fakechroot chroot ROOTFS apt-get update
 ---> Running in 9f203eea9b98
*** stack smashing detected ***: terminated
Aborted (core dumped)
The command '/bin/sh -c fakechroot chroot ROOTFS apt-get update' returned a 
non-zero code: 134

I am reporting this from my trixie system, but the same happens on bookworm 
systems, and bookworm is used inside the relevant Docker container.

-- System Information:
Debian Release: bookworm/trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_CH:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fakechroot depends on:
ii  binutils   2.42-4
ii  libfakechroot  2.20.1+ds-17

fakechroot recommends no packages.

fakechroot suggests no packages.

-- no debconf information

Bug#409444: logcheck: ignore "last line repeated $n times" if prevline matched

[Richard Lewis]

On Sat, 03 Feb 2007 10:29:38 +0100 Jonas Koelker  wrote:

> I (think I) want to see how many times the messages I care about are
> repeated.  This means I can't ignore "last line repeated $n times"
> messages (obviously).  But since those can also occur after messages
> that are ignored, I can't _not_ ignore them either.  So, I lose.
>

rsyslog has disabled the "feature" which produces this message, see
https://www.rsyslog.com/doc/configuration/action/rsconf1_repeatedmsgreduction.html

so this bug from 2007 can, i think, be closed.

Bug#690608: logcheck-database: consider to add ignore.d.server/rrdcached

[Richard Lewis]

On Tue, 16 Oct 2012 03:14:20 +0200 Sebastian Steinhuber
 wrote:

> Dear Maintainer,
> to drop (slightly boring) messages from the package rrdcached of the
> form:
> Oct 15 22:59:29 dds rrdcached[12045]: flushing old values
>
> I added a file named ignore.d.server/rrdcached, containing the line:
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rrdcached\[[0-9]+\]: flushing
> old values$

Hi Sebastian,
over a decade ago you reported the above bug against
logcheck-database: im sorry no-one replied before today!

Is this rule still valid?  im thinking things may have moved on, and
wondering if the bug is still valid.

Bug#442244: [Logcheck-devel] Bug#442244: logcheck-database: should include the filters from cyrus-imapd-2.2

[Richard Lewis]

On Fri, 14 Sep 2007 14:06:58 +0200 martin f krafft  wrote:
> also sprach Alex Prinsier  [2007.09.14.1344 
> +0200]:
> > Please copy over the filters from cyrus-imapd-2.2. I'm running
> > logcheck on a loghost, which doesn't run cyrus itself. There might
> > be a better alternative to copying the file, but anyhow it should
> > be in logcheck-database.

> logcheck is not designed to be run on a loghost, really. I know it
> would be nice, but it's not the general use case. You'll fare best
> if you copy the file over, or simply install the cyrus-imapd-2.2
> package on the loghost and disable all services.
>

I am tempted to  close this bug from 2007:
- No-one has objected to the above two paragraphs since 2007, over a decade ago
- The design of logcheck is that rules can be installed by packages
and logcheck-database should not duplicate that, and it would risk
file conflicts and out of date files.
- People who want to run logcheck on a "loghost" can copy the rules -
for example from sources.debian.org or salsa.debian.org

HOWEVER:  maybe this bug has value as it suggests that the logcheck
ignore.d.serve/cyrus rules should actually be deleted:

apt-file search cyrus | grep logcheck
cyrus-common: /etc/logcheck/ignore.d.server/cyrus-imapd
cyrus-common: /etc/logcheck/violations.ignore.d/cyrus-common
cyrus-common: /etc/logcheck/violations.ignore.d/cyrus-imapd
logcheck-database: /etc/logcheck/ignore.d.server/cyrus

Bug#588312: [Logcheck-devel] Bug#588312: logcheck-database: updated rules for many packages

[Richard Lewis]

Closing this bug from 2010 (14 years ago!) -- the then-maintainer
found that most of the suggestions were either already present or
should not actually be added, for various reasons.

A requested was made to resubmit as more independent bugs - if that
was done, we dont need this bug, and if not that suggests there is no
interest in proceeding.

Either way, the best thing seems to be to close this bug. Please
reopen with updated rules, if needd


On Thu, 08 Jul 2010 13:58:47 +0200 Hannes von Haugwitz
 wrote:
> Hi,
>
> Like Gerfried said, please file different bug reports for different
> packages the next time.
>
> Some comments about your rule suggestions:
>
> Radosław Antoniuk wrote:
> >> #dkimproxy
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: connect from 
> >> .*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: DKIM signing - 
> >> signed; .*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: DKIM signing - 
> >> skipped; .*$
> >
> > No rules at all.
> >
> >
> > Jul  7 12:39:21 hosting dkimproxy.out[1508]: DKIM signing - skipped;
> > message-id=,
> > from=
> > Jul  7 12:39:21 hosting dkimproxy.out[1508]: DKIM signing - signed;
> > message-id=,
> > from=
> > Jul  7 12:39:21 hosting dkimproxy.out[1508]: connect from 127.0.0.1
> >
>
> I don't see the need of wildchar .* here.
>
> >
> >> #ssh
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+\]: error writing 
> >> /proc/self/oom_adj: Operation not permitted$
> >
> > Not there.
> >
>
> Looks like an error for me, maybe #555625?
>
> >> #ntp
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ ntpd\[[0-9]+\]: kernel time sync status 
> >> change 4001
> >
> > No config at all
> >
>
> This message shouldn't occur anymore (see #498992).
>
> >
> >> #syslog-ng
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslog-ng\[[0-9]+\]: Log statistics;.*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslog-ng\[[0-9]+\]: Configuration 
> >> reload request received, reloading configuration;$
> >
> >
> > syslog-ng[31823]: Log statistics; processed='destination(d_error)=3',
> > processed='destination(d_messages)=298',
> > processed='src.internal(s_src#1)=90',
> > stamp='src.internal(s_src#1)=1278499023',
> > processed='destination(d_syslog)=90', processed='center(received)=0',
> > processed='destination(d_xconsole)=3',
> > processed='destination(d_newscrit)=0',
> > processed='destination(d_auth)=1452',
> > processed='destination(d_daemon)=1',
> > processed='global(payload_reallocs)=0',

Bug#511483: logcheck-database: please add rules for rkhunter

[Richard Lewis]

package: logcheck-database

# think it's reasonable to add rkhunter rules - although the ones in
this bug need updates
severity 511483 normal
tags 511481 - wontfix

Bug#592365: logcheck: ignore rules for transmission-daemon

[Richard Lewis]

On Tue, 10 Aug 2010 10:28:54 +1000 Nemo  wrote:

> > ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ 
> > transmission-daemon\[[[:digit:]]+\]: Saved 
> > "/var/lib/transmission-daemon/info/.*" \(bencode.c:1651\)$
> > ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ transmission-daemon\[[0-9]+\]: .* DHT 
> > announce .*\(tr-dht.c:(669|637)\)$

Hi Nemo, in 14 years ago you reported a bug against logcheck-database
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592365 -

I believe you suggested that the above be added to logcheck.

It;s a shame no-one ever replied to you - let me at least try now:

Are these rules still needed for transmission-daemon? I imagine there
may have been several changes to message formats since then.

Bug#1015201: logcheck: Update patterns, here: rsyslogd

[Richard Lewis]

On Sun, 17 Jul 2022 17:28:11 +0100 Richard Lewis
 wrote:
> > The pattern for rsyslogd can be improved. Please add the following
> > line:
> >
> > imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' \(fd 3\) from 
> > systemd.  \[v8.2206.0\]
> >
> > You might want to generalize the fd (on my system it is always fd 3,
> > but I don't know if this is general) and possibly the version number;
> > ideally this would remain in sync to whatever is in testing.
>
> I have the following rules in etc/logcheck/ignore.d.server/local-rsyslog
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ systemd\[1\]: rsyslog\.service:
> Sent signal SIGHUP to main process [0-9]+ \(rsyslogd\) on client
> request\.$
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd\[[0-9]+\]: \[origin
> software="rsyslogd" swVersion="[0-9.]+" x-pid="[0-9]+"
> x-info="https://www.rsyslog.com"\] rsyslogd was HUPed$
>
> so you might like to add those too. (i believe these are caused by
> logrotate via /usr/lib/rsyslog/rsyslog-rotate , the latter being part
> of rsyslog). they are relevant to bullseye systems

Hi Helge. Apologies no-one has replied to this bug report for 2 years
and that this response isnt going to be what you want!

The rules for rsyslog are actually provided by rsyslog not
logcheck-database so this bug should be against rsyslog --
however, im not sure rsyslog produces those messages about HUP any
more so maybe it should be closed rather than reassigned?

I do see the one about the unix socket but
a) i wonder if that's a bug rather that should be hidden?
b) I also think i only see it  "startup" (ie only produced when the
system boots / service starts):
debian usually doesnt add rules to filter startup messages as it tends
to add a lot of rules

(apologies if i am wrong on this - i dont usually have rsyslog
installed, but ve been running it in a container for testing some
upcoming changes to logcheck and
i don't see either of the messages above despite running for several days).